Uno dei punti forti grande di Ruby on Rails è che si astrae via di accesso al database in modo che tu non devi preoccuparti di scrivere SQL quando la vostra applicazione. Purtroppo, questo database nasconde accessi da parte degli sviluppatori, che possono portare a seri problemi di prestazioni. La soluzione a questo problema non è quindi più lontano dai Binari log.

Consideriamo questa semplice applicazione Mixx-ish, che visualizza un elenco di storie:

Il controllore:
@stories = Story.find(:all, :conditions => "some condition")

Il punto di vista:
<ul>
<% @stories.each do |s| %>
<li>"<%= s.title %>" by <%= s.submitter.display_name %>
with <%= s.comments.count %> comments
</li>
<% end %>
</ul>
(Vorrei sottolineare che Jason e Doug creare markup molto meglio di questo. Questo è ciò che si ottiene quando un ragazzo di backend, come mi scrive il codice al fine di dimostrare qualcosa - non avremmo nulla usare questo brutto nel codice di produzione Mixx.)

Sembra abbastanza ragionevole, giusto? Ma, come il numero di articoli sulla lista cresce, performance va rapidamente male. Scopriamo perché.

In primo luogo, un esempio di output di un percorso di questo codice:

• "Obama vince!" Di Joe con 3 commenti
• "Tempeste rabbia ovunque" da Julie 0 commenti
• "Mixx lancia" di Chris con 3 commenti
• "Allevamento Melanzana" di Chris con 1 commenti

Avanti, date un'occhiata al Rails registro quando questa lista è generato. Questo può essere trovato nella directory di applicazione nei log / development.log:
Story Load (0.000911) SELECT stories.* FROM stories
Rendering stories/show
User Load (0.000601) SELECT * FROM `users` WHERE (`users`.`id` = 176)
Comment Load (0.000391) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 545)
User Load (0.000441) SELECT * FROM `users` WHERE (`users`.`id` = 188)
Comment Load (0.000364) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 99)
User Load (0.000424) SELECT * FROM `users` WHERE (`users`.id' = 6)
Comment Load (0.000358) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 85)
User Load (0.000408) SELECT * FROM `users` WHERE (`users`.`id` = 6)
Comment Load (0.000269) SELECT count(DISTINCT `comments`.id) AS count_all FROM `comments` WHERE (`comments`.thingy_id = 18)
La prima linea è ragionevole - che è appena trovato la lista di storie. Ma guarda cosa succede quando il rendering della vista: per ogni storia visualizzato, ci sono due interrogazioni inviate al database. Non c'è da meravigliarsi che la generazione di un lungo elenco di storie richiede molto tempo quando si è l'emanazione di due interrogazioni per ogni storia.

Un rapido sguardo al codice ci dice che cosa sta accadendo: l'espressione "s.submitter.display_name" ottiene il presentatore della storia (che è nel modello Storia come un attributo belongs_to) ed estrae la display_name da esso. Ma che richiede un recupero di database (la query sulla tabella utenti). E l'espressione "s.comments.count" richiede la query sulla tabella commenti.

Fortunatamente, c'è una serie di tecniche che possono essere utilizzate per eliminare queste query in più. Questi includono:

1. L'uso del "include:" Direttiva quando il recupero dei dati. Ad esempio, modificare il codice sopra controller come segue:
@stories = Story.find(:all, :conditions => "some condition", :include => [:submitter])
e tutte le query tabella utenti di cui sopra sono sostituite con una sola query sulla tabella degli utenti.

(Nota: una volta, Rails potrebbe essere inefficace nella sua attuazione di quanto previsto: direttiva include. Fortunatamente, questo è fissato in Rails 2.0, quindi non c'è più alcuna ragione per evitare di: include).

2. Negozio frequentemente utilizzati dati nella tabella padre. Certamente, questa è una violazione dei principi di normalizzazione dei database. Secondo questi principi, non vogliamo duplicare i dati nel database. Ma in alcuni casi, l'incremento delle prestazioni che si ottengono da denormalizzazione valgono i potenziali problemi con i dati che vanno fuori sincronismo. Soprattutto quando i dati in questione non è cruciale.

In questo caso, abbiamo aggiunto un campo comment_count alla tabella storie. Usiamo le azioni after_create e before_destroy sul modello commento a tenere il campo comment_count aggiornato - quando creiamo un nuovo commento, viene incrementato il valore comment_count per la sua storia di genitore. (Abbiamo preso una decisione cosciente che, mentre ci potrebbero essere intelligente e riesce a mantenere accurati comment_count, possiamo vivere se non è corretto per alcune storie.) Dopo di che, si può utilizzare il campo comment_count in Story invece di comments.count, così evitando la query necessarie per ottenere il numero di commenti per una storia. Il panorama che ne risulta è la seguente:
<ul>
<% @stories.each do |s| %>
<li><%= s.title %> by <%= s.submitter.display_name %>
with <%= s.comment_count %> comments
</li>
<% end %>
</ul>
In concomitanza con il cambiamento osservato nel controller # 1, il log delle query ora assomiglia a questo:
Story Load (0.006564) SELECT * FROM `stories` WHERE ( some condition )
User Load (0.000943) SELECT * FROM `users` WHERE (`users`.id IN ('127','193','6','249','216','239','91','240','196','37','93','176', '188','244','235','136'))
Rendering stories/show
Che cosa usato per prendere nove interrogazioni (e potrebbe facilmente salire a più del numero di storie aumentato), tiene due.

3. In alcuni casi, è possibile trovare i dati necessari negli attributi del modello. Se si può evitare in tal modo il recupero attraverso un belongs_to o del rapporto di has_X, quindi farlo

Non è un esempio di questo nel codice di esempio. Ma supponiamo che non ci vuole mostrare l'effettivo presentatore di una storia nell'esempio precedente, ma vogliamo visualizzare la storia in modo diverso se viene presentata dalla persona che lo visualizza la pagina. (Nel nostro caso, il modello d'uso del visore della pagina è sempre contenuto nella variabile user @.) Potremmo utilizzare uno dei seguenti metodi per eseguire questo test:

if @user == story.submitter # bad! Requires database retrieval of submitter
if @user.id == story.submitter.id # bad! Also requires retrieval.
if @user.id == story.submitter_id # good! No retrieval required.
Anche se si utilizza il: direttiva include per ottenere il presentatore, i primi due metodi richiedono almeno un recupero del database per la pagina.

Un altro caso comune comporta una prova per l'esistenza di dati relativi ad un modello attraverso un belongs_to. Per esempio, supponiamo di voler verificare se una storia ha un presentatore a tutti. Qui ci sono due modi per farlo:

if story.submitter # bad - retrieves submitter if present
if story.submitter_id # good - no retrieval required
In sintesi, anche se Rails permette di astrarre accessi al database via, se si desidera che l'applicazione da eseguire, è necessario essere consapevoli di come esso utilizza il database. Un metodo eccellente per essere a conoscenza è quello di rivedere il registro di Rails, mentre si sviluppa l'applicazione, con particolare attenzione alle istanze di ripetere la stessa query (come nell'esempio precedente, in cui la query degli utenti e commenti ripetere tabelle). In realtà, si dovrebbe rivedere frequentemente dai Binari log quando si crea un'applicazione che deve eseguire bene.

Attraverso la storia di Internet, ci sono punti di flesso in cui una nuova tecnologia hits "le masse" e davvero decolla. Quasi universalmente, il filo comune in una rapida espansione e l'adozione di una tecnologia è un grande passo avanti, non di pura tecnologia, ma un importante passo avanti nel design. In particolare, un importante passo avanti in termini di facilità d'uso.

Prima di Google ha creato una interfaccia di ricerca semplice morto, la stragrande maggioranza delle persone la navigazione utilizzati come metodo principale per navigare nel web. Prima di Mosaico in visual semplice la navigazione, la navigazione basata su testo attraverso Archie e Veronica erano la norma. Apple ha fatto di musica online che consumano facilmente con iTunes e iPod. AOL fatto "Getting on-line" facile per mamma e papà. Più di recente, YouTube ha reso facile la condivisione di video su Internet per ogni liceale nel mondo.

La storia di Internet è piena di tecnologie che erano favolose, ma mai del tutto reso mainstream. A Mixx, siamo così in amore con l'idea di OpenID che vogliamo fare la nostra parte per rendere sicuri OpenID non è relegato ai libri di storia nel "avrebbe potuto essere" capitolo.

Per chi è nuovo a OpenID, l'idea è semplice. Dopo aver creato un account con un provider OpenID, ti viene assegnato un identificativo univoco (un URL personalizzato) che si utilizza a sua volta, per accedere a e registrarsi con i siti che supportano OpenID ("consumatori", come li chiamano). L'obiettivo di OpenID è duplice. In primo luogo, voi, cari utenti, in grado di creare il tuo OpenID con un provider di account di fiducia e, di conseguenza, estendere la fiducia di siti e servizi di propria scelta. Non sarà più necessario consegnare un indirizzo email e una password per ogni nuovo (potenzialmente fly-by-night), un'applicazione web che viene avanti. In secondo luogo, dal momento che in genere hanno un OpenID unico, non dovrete cercare di ricordare quale nome utente e la password utilizzati su questo sito o quel sito. È sufficiente ricordare che si è utilizzato OpenID!

OpenID, poiché è creazione, ha compiuto incursioni grande sul web. Alcuni dei maggiori fornitori di servizi là fuori (AOL, Yahoo!, Ecc) sono diventati OpenID provider, dando OpenID a milioni e milioni di persone. Ogni settimana, almeno una lancia sito con OpenID o di un sito esistente OpenID aggiunge funzionalità per il loro processo di login o registrazione. Il problema, come abbiamo osservato, è che mentre login OpenID e la registrazione è di essere rapidamente aggiunti ai siti, la sua presentazione manca la progettazione necessaria per mamma e papà per afferrare il potere di OpenID.

Oggi, siamo orgogliosi di lanciare il nostro prendere in materia di registrazione e login OpenID. Se swing dagli Login o Registrazione pagine e vedrete qualcosa di nuovo. Per Mixxers esistenti, la schermata di login sarà contestuale al vostro attuale metodo di login (o username / password o OpenID).

Per Mixxers nuovo, puoi registrarti con un AOL, Yahoo!, O account Facebook. Standard di registrazione OpenID è ancora disponibile. Se, da alcuni scherzo del destino, non si dispone di un account con uno dei servizi di terze parti che supportano attualmente, è ancora possibile registrare con il tuo indirizzo email. Sebbene Facebook non è OpenID per-sé, sia AOL e Yahoo! Di registrazione e di login OpenID utilizza sotto le coperte senza chiedere gli utenti per i loro URL OpenID. In caso di AOL, chiediamo il vostro nome account AOL o AIM e shuffle si stacca sulla pagina di accesso appropriato. Accesso a Yahoo! E la registrazione è ancora più semplice-clic honkin grande '"Login / Registrati con il tuo ID Yahoo!" Pulsante e noi ci occuperemo del resto.

Abbiamo fatto un passo avanti e ha aggiunto una grande funzione di login: teniamo traccia del metodo ultimo di login utilizzato e riprogettare la pagina basata su questo. Quindi, se si utilizza Facebook per il login, ti verrà presentato con una grande icona di Facebook e pulsante. Non c'è bisogno di cacciare e di scegliere attraverso le nostre opzioni di login!

L'ultimo pezzo del puzzle è la gestione dei conti. Passare alle impostazioni dell'account e fare clic sulla nuova scheda "Account. Da lì, è possibile aggiungere e rimuovere i vostri account di terze parti a proprio piacimento. Collegando il tuo account diversi attraverso il web con il tuo account Mixx, è possibile utilizzare uno di questi metodi per accedere a Mixx. Questo è un primo grande passo verso l'obiettivo di interoperabilità fra Mixx e vostri siti web preferiti e applicazioni.

Abbiamo messo un bel po 'di lavoro nella nuova registrazione e l'esperienza di accesso e ci auguriamo che i miglioramenti utili e, soprattutto, facile. Come sempre, apprezziamo i tuoi commenti e ansioso di sentire quello che hai da dire!

~ Jason (e il resto della squadra Mixx)

Da quando ho raggiunto il team Mixx (un anno e qualche cambiamento fa) e ha iniziato a sfornare il codice HTML, CSS e JavaScript che si vede e utilizzare tutti i giorni, ho fatto un punto di costruire con le caratteristiche di accessibilità in mente. Mixx ha una grande varietà di utenti che comprende tutte le razze, i colori, credo, e capacità. E 'stato (e rimane fino ad oggi) importante per noi che mettiamo a disposizione una grande esperienza per i nostri utenti, mentre non lasciando anyone fuori al freddo.

Come molti di voi sanno, c'è un sacco di interattività a Mixx-voto, la comunicazione, la presentazione, interagendo con YourMixx-la lista continua. Ciascuno di questi elementi comporta una diversa interazione con la domanda e ogni uno di loro consiste nel manipolare i contenuti sullo schermo usando una combinazione di JavaScript e CSS.

Nel tentativo di accogliere gli utenti (o, più direttamente, il loro browser di scelta) che hanno disattivato JavaScript, si prende la strategia di visualizzare tutti i contenuti di default e quindi utilizzando JavaScript per nascondere gli elementi del caso. Il metodo più semplice per osservare esempio di questo è sulle pagine permalink. Con Redux recente del permalink , abbiamo aggiunto alcune nuove "schede" (per mancanza di un descrittore migliore) sotto la voce informazione e soprattutto i commenti: attività, su questo sito, e correlati.

Durante la navigazione a una pagina permalink, a seconda di come zippy la connessione a Internet, è possibile notare che le tre schede sono expaned e impilati uno sopra l'altro inizialmente. Dopo una breve pausa, faranno scattare via e possono quindi essere accessibili cliccando sul loro rispettivo pulsante. Questo è, al massimo di base, la situazione sopra descritta. Contenuto della pagina carichi. JavaScript fa il suo lavoro e nasconde i pezzi appropriati.

In un mondo perfetto, questo accadrebbe istantaneamente e nessuno se ne accorgesse. Nel mondo reale, le connessioni Internet sono variabili, singhiozzo web server e risorse esterne (come Google Analytics) hanno l'effetto collaterale di stallo lancio di script locale. L'ultimo punto è quello di preoccupazione per la nostra discussione. Steve Souders, nel suo eccellente libro High Performance Web Sites , va in gran dettaglio perché questo stallo accade. Check out Capitolo 6 su "problemi con script."

Allora che cosa facciamo? Diamo prima un'occhiata a come funziona attualmente Mixx.

Come abbiamo osservato, il nostro codice HTML e tutto ciò che di stile CSS della pagina e gli elementi di visualizzazione di default. Una volta che tutto è caricato, il codice JavaScript Mixx (utilizzando jQuery , un soggetto per un altro post) usa $ (). ready () per sparare nostri eventi onload. Il bit appropriato nascondere e abbiamo finito. Questo è grande quanto "migliori pratiche" e tutto ciò che riguarda, ma meno-che-grande dal punto di vista percettivo.

Robert Nyman , nel suo post come nascondere e mostrare il contenuto iniziale, a seconda se è disponibile il supporto di JavaScript , delinea una tecnica in cui si aggiunge un elemento di <script> <HEAD> del documento which chiama una funzione anonima che, a sua volta , aggiunge un file CSS alla tua pagina. Il file CSS contiene una sola riga con un selettore (nel suo caso un selettore ID-based) che indica un elemento da non visualizzare.

E 'una soluzione brillante che supera il problema onload introdotto da attività a distanza. L'unico emendamento che vorrei fare al suo esempio è quello di usare una classe base, piuttosto che selettore ID-based. In questo modo, è possibile impostare una singola classe (". Alt", per esempio) e si applica a tutti gli elementi che si desidera nascondere.

Semplice come quello, davvero. Robert ci offre una soluzione estensibile a un problema che è stato sviluppatori sempre più preoccupante. Allora perché, allora, vi chiedo, è Mixx non implementato questo? "Time", per lo più. Siamo una piccola squadra qui con un elenco enorme di cose da fare! Vi prometto, però, che questo sarà attuato come abbiamo tempo.

Avete trovato altre soluzioni efficaci a questo problema? Se è così, ci lasci una nota nei commenti!

5 tasti a fare il salto dalla progettazione visiva per Web Designer

Quindi, prima andiamo definire, (la mia definizioni quando si parla di web)

Un visual designer: Qualcuno che disegni grafici che fanno strada sul web.

Un web designer: qualcuno che abbia le capacità di visual design, ma comprende anche come scrivere pulito, semantico, basato su standard HTML / XHTML e CSS.

Quest'ultimo comprende la tela che l'inchiostro sta succedendo. Il primo sa mescolare l'inchiostro.

1. Che tipo di studente sei?
Il mio più grande errore della mia carriera non è stata prima di rispondere a questa domanda ho cercato di imparare "dall'altra parte" per la prima volta. Sarei stato scritto anni prima, se markup che avevo appena raccolto il giusto tipo di materiali. tipo nero su carta bianca con un grafico occasionale / grafico è stato il primo metodo di auto-formazione. Big Time fallire. Semmai mi spaventò indietro nel mio buco photoshop-only.

Cinque anni più tardi ho preso in mano un libro di Jeffery Zeldman. Se stai leggendo questo blog, è probabile che ne ha sentito parlare: " Progettare con gli standard web ". Questo libro mi ha salvato la carriera. Il libro ha detto di ciò che potrebbe-e dovrebbe-online storicamente da fare. Ha aperto le porte che prima erano chiusi - diamine, morto imbullonati e Master bloccato. Il settore chiave in cui il libro mi ha colpito di più è che ha preso il "fattore paura" fuori della parola "sviluppo." Invece di ottenere lo sviluppo in termini di design, progettazione semantica e basata su standard, è diventato la norma. Il contesto storico anche svolto un ruolo fondamentale. Mi ha aiutato a capire che cosa era giusto e cosa è sbagliato, e ha spiegato come le limitazioni della tecnologia ha causato un sacco di quella sbagliata.

Guardando indietro, questo è stato il giocatore chiave per avermi alla fase successiva. Ogni libro o aiutante di formazione professionale diverso acquistato dopo questo aveva questo in mente. Che libro di Zeldman ha portato me che gli altri non sono stati grafica e colore. Si parlava la mia lingua e convogliate le risposte alle domande che avevo.

2. Sei davvero sicuro che questa è la vita che vuoi?
Alcune persone appena fuori piano non è in grado di fare lo switch. Non sarò mai uno sviluppatore di back-end e mi va bene con quello. Il mio cervello proprio non funziona in questo modo. In questo caso, non c'è nulla di sbagliato solo facendo il visual design. Per me è stato il passo logico successivo nella direzione che volevo andare.

3. Chi lo sa? Perché sarà di aiuto.
Se gran parte dei libri mancato di me, e le classi non è mai entrato nei pressi di consegna, sono state quelle connessioni che ho fatto nel settore che mi hanno veramente aiutato a superare la gobba. Partecipano a conferenze, facente parte della scena locale o semplicemente inviando una e-mail a caso ad un "weblebrity" sempre portato più di qualsiasi ritorno letto il libro o classe frequentata. Quindi non abbiate paura di raggiungere.

4. Stai andando a rovinare, va bene, basta assicurarsi di avere gli strumenti adatti quando lo fai.
Avete intenzione di fare degli errori, tutti noi. Qualcosa di stupido come la chiusura di un tag di paragrafo vi farà a voler strappare i capelli. Stai tranquillo, assicuratevi di avere gli strumenti necessari per l'attività e continuare a tenere a.

Strumenti consigliati

1. Firefox - Scarica l'ultima versione
   * estensione Firebug per Firefox
   * Web Developer Toolbar per Firefox
2. Parallels - Scarica l'ultima versione
   * Piaccia o no, IE6 è ancora uno dei browser più usati là fuori. Voi utenti Mac dovranno questo test.
3. Opera - Scarica l'ultima versione
   * Dragonfly - Simile a Firebug, ma per Opera (voce è che la chiamò così perché le libellule mangiano firebugs)
4. HTML e CSS di riferimento - HTML Dog
5. Un grande sito di riferimento che ci ha portato da Dan Cedarholm

5. Assicurarsi che ci si diverte.

Fate ciò che amate e amerete quello che fate. Questi ragazzi sono d'accordo:

"Scegliere un lavoro che amate, e non dovrai mai lavorare un giorno nella vostra vita." - Confucio

"Non ho mai fatto un giorno di lavoro nella mia vita. E 'stato tutto divertente. "- Thomas A. Edison

Un grande vantaggio di aver trascorso un lungo periodo in un settore è che si vedono certi schemi si ripetono nel tempo. Uno di questi modelli ha avuto un impatto importante sulla nostra decisione di utilizzare Ruby on Rails per Mixx.

Uno dei miei primi lavori era ad un imprenditore di difesa chiamato Logicon. Logicon avuto una serie di contratti con varie agenzie di intelligence, molti dei quali coinvolti notizie trattamento ricevuto via newswire, categorizzare quelle storie, e di consegnarli al analisti che avevano manifestato interesse per un argomento specifico. Così, per esempio, un analista specializzato in Russia potrebbe iscriversi a tutte le storie che menzionato Vladamir Putin, la Russia e la Georgia (ma non ha fatto menzione di Atlanta).

Questo software era stato scritto per i mainframe IBM in the linguaggio assembly IBM. Esso potrebbe essere usato soltanto in tale ambiente, ed è stato non adattabile ad altri sistemi. Il mio lavoro è stato di take the technology, trasforma lo schermo in prodotti off-the-shelf, e favorire il pacchetto per l'uso da altri. La speranza era che avremmo potuto vendere a una vasta gamma di clienti, sia dentro e fuori del governo.

Uno dei nostri grandi sfide precoce è stato quello di ottenere il permesso di scrivere il nuovo prodotto nel linguaggio di programmazione C. Il nostro locale Logicon vice presidente, l'uomo che controllava la luce verde, era stata un programmatore in linguaggio assembly, che hanno lavorato al sistema che noi eravamo adegua. Fu sospetto che avremmo potuto ottenere le prestazioni necessarie per C. (rendimento elevato è stato il grande punto di vendita di questo prodotto, che avrebbe dovuto elaborare migliaia di richieste nei confronti di diversi racconti in arrivo al secondo, un grosso problema con l'hardware di il tempo.) aveva poca esperienza con il C se stesso, e così aveva bisogno convincente.

Abbiamo costruito un prototipo che ha mostrato che, mentre l'implementazione del linguaggio C non era veloce quanto la versione assembler originale, si è più che abbastanza veloce per il nostro mercato di destinazione. Questo, combinato con gli altri vantaggi della C (maggiore portabilità e produttività programmatore) , fu sufficiente a convincerlo a va bene il progetto. E così ho trascorso i prossimi anni della mia vita dell'edificio e del mantenimento della Logicon Message sistema di diffusione (LMDS), che finì per essere utilizzato da un certo numero di agenzie governative. e che ha portato direttamente a me essere assunto a AOL, che hanno acquistato sia LMDS e, infine, da me Logicon.

(Non sono sicuro se LMDS è ancora in uso presso AOL. Ma era come di un paio di anni fa, viene utilizzato come parte del sistema che classifica le notizie per la fabbrica di AOL Feed. Non male, per un pezzo di software che è stato originariamente scritto vent'anni fa.)

Questa era la mia prima volta l'incontro con la discussione tra un vecchio, la lingua stabilita e un linguaggio più recente che, pur non essendo il più efficiente in termini di velocità del processore, è molto più efficiente in termini di tempo per i programmatori.

Flash Forward dieci anni. C era saldamente radicato in AOL, come è stato I. Ma un nuovo linguaggio stava guadagnando importanza - Java. E l'argomento è sorto: AOL dovrebbe rendere Java il linguaggio-di-scelta per nuove applicazioni?

Java avuto un sacco di vantaggi rispetto C. E 's un linguaggio molto più facile da usare, e non è vulnerabile ad alcuni bug veramente doloroso che è possibile creare in C. (Una volta ho visto un progetto C di una dozzina di persone un ritardo di settimana a causa di un mal riposto e virgola.) Tutto questo si traduce in una maggiore produttività dei programmatori.

Ma Java non è mai sta per essere efficiente come C in termini di risorse macchina. Alcune delle caratteristiche che fanno di Java sicuro anche il costo cicli di processore. Questo è indipendente dal compilatori coinvolti: anche con le migliori compilatore del mondo, un programma Java non out-eseguire un programma equivalente C.

Prendiamo un esempio: matrice di verifica dei limiti. In C, è possibile creare un array di dieci elementi, e poi felicemente chiedere di accedere alla voce undicesimo. C consentirà a questa - il principio guida della C è che il programmatore sa cosa sta facendo, in modo anche se sembra stupido, basta fare quello che dice il programmatore, dannazione! Ciò può causare ogni tipo di effetto sgradevole in C. (La durata di una settimana di ritardo che ho citato sopra il risultato di proprio un bug.)

Ma ogni volta che si accede a un elemento di un array in Java, i controlli Java che non state andando fuori dai limiti. Un tentativo di accedere alla voce undicesima un un array di dieci voce si tradurrà in un errore di Java che individua esattamente dove è andato storto. Il bug si troverà nel giro di pochi minuti, non giorni.

Ciò consente di risparmiare un sacco di tempo per i programmatori. Ma a fare quelle di matrice limiti processore controlla i costi di tempo - ogni volta che si accede a un elemento di un array in Java, deve verificare che l'accesso è in limiti. Il tempo di elaborazione è sacrificato per il tempo programmatore.

AOL corse su alcuni parametri e ho trovato che un programma Java avrebbe preso in giro due volte il tempo CPU di eseguire il programma C equivalente. Ma, soprattutto considerando che il fattore limitante era di solito sulle prestazioni di I / O non e CPU, e dato che il tempo del programmatore aveva ottenuto più costosa, mentre il tempo di CPU era costantemente sempre più economico, questo è stato un buon trade-off. E così AOL ha adottato la nuova politica che, a meno che non vi era una buona ragione per fare altrimenti, dovrebbe essere fatto in Java.

Ora veniamo al presente, il momento inevitabile quando c'è un nuovo capretto sul blocco, un nuovo linguaggio che è impegnativo Java. E 'più facile sviluppare una web application in Ruby on Rails che in Java. Sì, Ruby non è così tempo efficienti in termini di tempo di elaborazione, ma è molto più efficiente in termini di tempo per i programmatori. e la trasformazione non è il fattore limitante nelle maggior parte delle applicazioni in ogni caso.

In altre parole, è esattamente lo stesso argomento come avevamo dieci anni fa al momento di decidere se attaccare con C o passare a Java. Che a sua volta era esattamente lo stesso argomento che abbiamo avuto dieci anni prima che, nel decidere se restare con assembler o passare a C. E 'un argomento che si riduce alla questione di ciò che il fattore limitante dello sviluppo è la seguente: tempo di CPU o di tempo per i programmatori. E nella maggior parte delle applicazioni, la risposta sarà tempo per i programmatori.

(In qualità di programmatore, posso solo dire che sono molto felice che i programmatori sono più costose di CPU. Spero che questo continui anche in futuro, con CPU sempre più economiche, mentre i programmatori di ottenere più costosa!)

Chiaramente, ci sono altri fattori coinvolti. Non dobbiamo tuffo nella nuova tecnologia proprio perché è nuova. E si può dimostrare che Ruby on Rails non è l'onda del futuro, nel modo in cui C e Java una volta.

Ma è interessante vedere gli stessi argomenti vecchi che si terrà più e più volte, ed è istruttivo, quando con questi argomenti, a ricordare come si rivelò l'ultima volta intorno.

Ho imparato una lezione importante di questa mattina, e ho pensato di condividerlo con voi. Per far fronte a condizioni errore, Ruby include, come fanno altre lingue, gestione di eccezioni. Questo ti permette di mettere tutto il codice che potrebbe generare uno o più errori in un blocco, e trattare con gli eventuali errori che si verificano in un altro blocco. Di gran lunga preferibile a tempi antichi, quando abbiamo dovuto controllare il valore di ritorno di ogni chiamata che potrebbe generare un errore, e trattare con esso sul posto, ognuno in modo unico. La gestione delle eccezioni è molto più pulito e più gestibile:

begin
# Do stuff that may fail here
rescue
# Deal with those failures here
end

La maggior parte degli articoli si occupano di gestione delle eccezioni Ruby vi dirà che il modo di intercettare le eccezioni è con il "Rescue" la linea. Ma si scopre, è solo una parte della verità. Un esempio fatto nel metodo IRB di Ruby console:

irb(main):001:0> begin
irb(main):002:1* raise "Haha, you missed me!"
irb(main):003:1> rescue
irb(main):004:1> puts "No I didn't!"
irb(main):005:1> end
No I didn't!

Fin qui tutto bene. Ma ora guardi questo:

irb(main):006:0> begin
irb(main):007:1* raise Exception.new("Haha, you missed me!")
irb(main):008:1> rescue
irb(main):009:1> puts "No I didn't!"
irb(main):010:1> end
(irb):7:in `irb_binding': Haha, you missed me! (Exception)

Woops! In tal caso, il salvataggio davvero perdere. Ma perché? "Non salvataggio" significa tutto salvataggio? Sono stato sorpreso di scoprire che non è così. Un ulteriore esempio dovrebbe chiarire le cose:

irb(main):016:0> begin
irb(main):017:1* raise "Better luck next time!"
irb(main):018:1> rescue => e
irb(main):019:1> puts("I caught a " + e.class.to_s)
irb(main):020:1> end
I caught a RuntimeError
=> nil
irb(main):021:0> begin
irb(main):022:1* raise StandardError.new("Better luck next time!")
irb(main):023:1> rescue => e
irb(main):024:1> puts("I caught a " + e.class.to_s)
irb(main):025:1> end
I caught a StandardError
=> nil
irb(main):026:0> begin
irb(main):027:1* raise Exception.new("Better luck next time!")
irb(main):028:1> rescue => e
irb(main):029:1> puts("I caught a " + e.class.to_s)
irb(main):030:1> end
(irb):27:in `irb_binding': Better luck next time! (Exception)

Ah-ah! Così, mentre sembra che il "salvataggio" sarebbe il modo più generico di trattare con le eccezioni di ogni tipo, in realtà non lo è. Esso prenderà StandardError (di cui RuntimeError è una sottoclasse), ma manca di eccezione. Il gestore di eccezione più generica risulta essere "Eccezione di salvataggio":

begin
# Do stuff here
rescue Exception
# I will catch everything, even stuff that "rescue" misses
end

Lezione imparata: se non si conosce l'unica cosa che si potrebbe avere a che fare con è StandardError o una delle sue sottoclassi, è meglio usare "Eccezione di salvataggio" di un semplice "salvataggio". Nevermind dei documenti che indicano che "il salvataggio" catture eccezioni, che è vero, ma fuorviante - in realtà le catture solo alcuni tipi di essi.

Mixx è costruito utilizzando il Ruby on Rails quadro. (Rails è il quadro. Ruby è il linguaggio.) Se si presta molta attenzione al mondo Internet tech, è probabile che ciò sollevare una grande domanda: non vuol dire problemi di scala?

Purtroppo, Twitter 's vari problemi con il ridimensionamento e l'affidabilità hanno gettato un sacco di FUD intorno a Rails. Dopotutto, Twitter è il più noto su scala Rails un'applicazione di grandi dimensioni sul web, e ha innegabilmente avuto problemi sia con scaling e la stabilità. (Anche se dopo aver lavorato con i tecnici eccellenti che Twitter appena acquisito con l'acquisto di Summize , mi sento fiducioso che i loro problemi saranno presto un ricordo del passato.) Un meme comune è che Twitter i problemi sono dovuti a Rails, e che pertanto sarebbe è possibile costruire una applicazione stabile e scalabile con Rails.

Dal momento che io sono il tipo che ha scelto di utilizzare Rails per Mixx, io ovviamente sono d'accordo. Lascia che ti dica il perché.

(Nelle note che seguono, parlerò di prestazioni e scalabilità. Mi rendo conto che questi non sono gli stessi. Tuttavia, esse sono strettamente legate, e non c'è FUD relativi sia intorno a Rails, quindi credo che valga la pena per la loro copertura sia in questa discussione).

1. 80-90% del tempo di risposta dell'utente-end non ha niente a che fare con qualche cosa sul server - è nella progettazione e realizzazione della pagina.

   Questo è il risultato di uno studio condotto da Yahoo!, Come riportato nelle Steve Souders eccellenti High Performance Web Sites (che io raccomando - ci dovrebbe essere una copia di questo libro in ogni negozio di sviluppo web). La maggior parte delle prestazioni è legata a questioni come l'impostazione corretta intestazioni cache delle immagini, riducendo il numero di oggetti sulla pagina, e la progettazione corretta di markup, CSS e JavaScript. Se si desidera che le pagine da caricare velocemente, guardate al vostro codice. (Questa è una delle molte ragioni che la prima persona che ho assunto quando sono venuto a bordo è stato Jason Garber, l'architetto UI Mixx's. E perché gli ho comprato una copia del libro Souders appena stato pubblicato.)

2. Prestazioni sul server è soprattutto una questione di design dei negozi di dati, non di codice dell'applicazione.

   Una tipica applicazione web prevede il recupero di dati da uno o più archivi di dati, manipolare in qualche modo, e il rendering della pagina per contenere tali dati. Di questi passi, quella che ha maggiori probabilità di causare problemi di prestazioni è il recupero di dati archiviati . Un database indicizzato male può causare gravi problemi, ed i guadagni maggiori prestazioni su una domanda ben scritto intenzione di coinvolgere archivi dati più veloce e una strategia di caching intelligente. Ma questi problemi non sono solo Rails - sono problemi comuni a tutte le applicazioni web, non importa in quale lingua viene utilizzata.

   (Mentre io so quasi niente sull'architettura Twitter, sono disposto a scommettere che i suoi problemi di scala hanno a che fare con il design memorizzare i dati, non il codice di applicazione. Se Twitter sono stati tradotti in un'altra lingua senza ridisegnare quei negozi, mi aspetto che avrebbe gli stessi problemi. sistemi di costruzione che richiedono mettendo insieme dati provenienti da più raccolte, con ogni utente che richiede un diverso insieme di dati, lo spinoso problema di progettazione di dati, indipendentemente dalla lingua.)

3. Rails supporta il ridimensionamento attraverso la duplicazione dei server applicativi.

   E 'facile sparare su come molti casi di applicazione e di server web di cui hai bisogno in Rails. Scaling hardware - gettando un'altra casella nel mix di partizionare carico - è altrettanto facile come con Rails è con qualsiasi altro contesto moderno applicazione web.

   Il fattore che limita a questo tipo di scala è la dimensione del database host - ma questo sta andando essere il fattore limitante non importa quale quadro di applicazione che si hanno. E gli stessi trucchi utilizzati in altre lingue per superare tali limiti opera in Rails.

4. Rails supporta il ridimensionamento attraverso il partizionamento della domanda.

   Un altro approccio tipico di scala comporta l'applicazione di partizionamento in sotto-applicazioni, ognuna delle quali viene eseguito su un insieme distinto di server. Questo può essere fatto in Rails facilmente come in qualsiasi altra lingua.

5. Rails ottimizza il tempo per i programmatori, non il tempo di processore - e questa è la scelta giusta.

   Non sto dicendo che Rails sta per eseguire e le lingue come Java. Ma Rails è ottimizzato per rendere la vita più facile per i programmatori, non i computer. Si tratta di un tema comune nella storia dei linguaggi di programmazione - un nuovo linguaggio arriva che è più facile per i programmatori, ma meno efficiente in termini di tempo del processore. C'è un post del blog in tutto questo - e prometto di scrivere qualche breve.

6. It is easy to write naive Rails code that performs poorly.  That's why we you shouldn't write naive Rails code.

   Clearly, any language can be used to write bad, inefficient programs.  But Rails, which abstracts out the database to make database access transparent to the programmer, probably makes it easier to write inefficient code.  It is easy to slap together a quick Rails application without worrying too much about the database - that's the great strength of Rails.  But to get performance, you need to pay attention to the details.  That isn't too difficult, and I'll blog sometime about how we've done it at Mixx.  But it is necessary.

   (I suspect that this is another cause of the bad reputation for performance that Rails has.  People throw together a quick Rails application, taking advantage of its ease in programming, and are then surprised when it doesn't perform.  But while building an application can be easy, we aren't yet at the point where building a complex and highly performant web application is easy.)

And there it is. At Mixx, we feel that Rails will serve us quite well as our application platform.  In fact, we have effectively bet the company's future on this belief.  I do not expect to be proven wrong on this - while Rails is not a perfect platform in terms of performance, and there are a number of improvements that could help (another fertile ground for a blog post), for our application it performs just fine.

Welcome to the Mixx Engine Room, the blog of the Mixx engineering team. Over time, we'll be writing posts describing various aspects of Mixx technology - how things are built, challenges that we've encountered in scaling, the reasons behind some of our technical decisions, and other details about our systems that we feel we can share with the world.

At Mixx, we're strong believers in community. We've read The Cluetrain , and we believe in it. This blog will be the engineering team's car on the Mixx Cluetrain.

But this blog is not like the movies. Here we roll the credits first. And so, without further ado, I give you the Mixx engineering team, listed by Mixx longevity:

- Raghu Somaraju is a backend developer here at Mixx, building the server code for several of our subsystems. When you first registered for Mixx, and the last time you logged in, you used Raghu's code. In his pre-Mixx days, Raghu worked at Yahoo! in the News and Information group for three years, where he met Mixx CEO Chris McGill. After Yahoo!, Raghu worked at Juno Online in India and at an online ad agency start-up that, alas, did not make it.

- Joe Dzikiewicz (hey, that's me!) wears many hats at Mixx, so it's a good thing he has such a big head. As CTO, he manages the development and operations teams. As backend architect, he does overall architectural design of the backend systems. As a backend developer, he codes much of that design, including the initial work on the voting, submission, and categorization systems. Before Mixx, Joe was a systems architect at AOL for ten years, most of it spent in the Search and Community development teams. If you ever searched for something on AOL, chances are you used some of Joe's code. When not writing Mixx blog, Joe blogs at www.drdzoe.com .

- Like most of the crew at Mixx, Jason Garber wears many hats, all of them stylish. His job as User Interface Architect implies that he has some sort of working knowledge of blueprints, AutoCAD, and spackle. This couldn't be farther from the truth. Unless, of course, you think of HTML as a blueprint, CSS as spackling paste, and JavaScript as AutoCAD, but that's a rather weak analogy. Poor analogies notwithstanding, Jason spends a good deal of time working with the rest of the Mixx team to ensure that everything that goes out the door is functional, attractive, and easy to use.

Prior to joining up with Mixx, Jason worked at a small design and marketing firm in Bethesda, MD, and did some time at AOL, most notably working on Ficlets, which won an award for Best CSS at this year's South by Southwest conference. Between breaths, he is also involved in the local DC tech scene, organizing events, shooting photography, and playing in a rock and roll band.

- Nathaniel Collinsworth is Director of Operations for Mixx. His responsibility is the smooth running of all the technical infrastructure that the company needs. This umbrella covers a large number of disciplines; database, web server, mail, security, monitoring and alarming, business continuity, etc. It also includes the less challenging, but just as critical, needs of the office personnel. Nathaniel spends much of his days ensuring that Mixx can continue to scale to the needs of it's growing user base. The first half of his career Nathaniel managed technology operations groups for non-technology companies, including non-profits, mining companies and the US Federal Government. The second half he has focused on the scalability and distribution of community applications on the web for AOL and for Mixx. He enjoys working at Mixx because he gets to use his broad range of talents to serve both the Mixx employees and our users.

- Bill Kocik also joins us from AOL, where he spent several years working in both Systems Operations and Software Engineering disciplines. At Mixx, Bill spends most of his time writing code that runs on the servers. Of note, he designed and implemented the Mixx API, and is largely responsible for the Site Mail feature, as well as once-per-day email notifications and the Google AdSense revenue sharing functionality.

- Doug March is a Senior Web Developer at Mixx. He spends much of his time bringing product designs and ideas to life. On the side, he helps dream up new features and dabbles in Search Engine Optimization. Doug started his career in the world of government consulting. Later, he found his niche and honed his skills at Revolution Health. In his free time he is usually on the links trying to collect that elusive 5th hole-in-one. When not enlightening you via the engine room, Doug blogs at http://doug-march.com .

So that's us. Follow this space to learn more about the way we think, and the way we do technology.