2009-05-16 17 views

risposta

11

La considerazione più importante non è quella di eseguire un ingegnere eccessivo al punto da ostacolare la costruzione e il lancio di qualcosa. La paralisi dell'analisi è il singolo più grande inibitore della produttività, dei progressi e dei risultati.

Sì, fare un po 'di pianificazione. Scegli un quadro. La perfezione in un quadro sarà impossibile da trovare perché non esiste, in parte perché non sai di cosa hai bisogno fino a quando non lo costruisci comunque. È probabile che, se scegli qualcosa, sarà meglio che scegliere nulla.

Sì, prova a scegliere strumenti flessibili e interoperabili per dove ti vedi.

Sì, cerca un buon set di funzionalità integrate in cui ti vedi andare nei prossimi 6-18 mesi. Cercare di guardare oltre non è comunque molto realistico dato che la maggior parte dei progetti cambia comunque andando verso la prima versione.

Quindi, scegli ciò che ti piace o ciò che ti è familiare. Non seguire la folla, fai quello che ti dà i risultati migliori, più veloce e spesso. Comprendi che potresti dover cambiare in futuro. Quindi, qualunque cosa tu costruisca ora, prova a usare i test unitari in modo da poter ridistribuire se necessario.

Se quello che stai costruendo sarà un grande successo, sarà un grande problema da avere, e sarà facile lavorarci una volta che guadagnerai, dato che sarai in grado di ottenere altri talenti per aiutarti .

Condividi quello che finisci a raccogliere e perché per la tua situazione - aiuta anche noi a imparare da te!

0

Dipende.

iniziare a guardare le vostre esigenze (funzionali o definiti dall'utente) (Non funzionante - aspetti che descrivono il sistema desiderato link text)

Avanti vorrei chiarire che cosa significa avere un'applicazione web scalabile. Definirlo come casi di test che possono essere chiaramente testati (deve supportare X pagine viste/secondi con tempo di risposta < Y secondi).

Una volta posizionati quei pezzi, vorrei esaminare il tipo di competenze che il mio team di sviluppo può supportare (per il progetto iniziale e la manutenzione in corso). Quindi trova alcuni casi studio di applicazioni in natura che usano un linguaggio o un framework simile. Se qualcun altro ha realizzato una scala specifica per linguaggio/quadro, è probabile che anche tu possa farlo.

Infine uscire e cercare alcuni provider di hosting che supportano la lingua, la struttura e i requisiti scelti.

2

In primo luogo sul linguaggio, in gran parte non importa. PHP, Java e .Net sono probabilmente i più grandi tre sono tutti provati nel senso che eseguono alcuni dei più grandi siti sul Web, quindi non ascoltare chi ti dice che uno è più adatto di tutti gli altri.

Alcuni potrebbero anche inserire Ruby e Django/Python in questo elenco. Non ho nulla contro di loro, ma non sono a conoscenza di nessun grande (diciamo i primi 50) siti che usano entrambi.

considerazioni Hosting dipendono da quanto in basso si desidera avviare ma fondamentalmente l'ordine è:

  1. condivisa;
  2. Server privato virtuale;
  3. Dedicato.

La scalabilità riguarderà in gran parte il design della vostra applicazione rispetto a qualsiasi lingua, struttura o fornitore. Schema efficiente del database, consegna efficiente e utilizzo di JavaScript/CSS e memorizzazione nella cache nella memoria sono tutti problemi comuni a qualsiasi linguaggio o framework.

+0

Siti Web scritti in Ruby: Twitter, Github, Amazon ... –

1

Lingua: raccomando qualcosa con buoni framework e buone librerie di test come Perl o Java.

Framework: dipende da cosa pensi di fare. Se inizi con un hosting che non consente FastCGI, è meglio evitare tali framework come Catalyst o Rails. Ecco perché amo CGI :: Application (principalmente Perl, ma anche in altri linguaggi), che può essere eseguito come CGI, FastCGI o mod_perl. Per lo sviluppo può essere eseguito dal proprio server web.

Hosting: niente è meglio del proprio server. Può essere il tuo server, server in leasing o server virtuale. Ma puoi iniziare con l'hosting più economico e quando hai bisogno di più, dovresti essere in grado di permettertelo.

+0

Ruby on Rails non richiede FastCGI, quindi non sono sicuro del motivo per cui il supporto FastCGI è pertinente. – Chuck

3

Non necessariamente sposare te stesso a una lingua o quadro. È possibile che alcune parti del tuo sito funzionino meglio con linguaggi e framework diversi rispetto ad altri. Ad esempio, tutti i siti di 37signals sono basati su Ruby on Rails, ma di recente hanno scritto un post sul blog su come la tecnologia sottostante di uno sia effettivamente scritta in Erlang ora perché è molto più facile fare la concorrenza in questo modo.

Ovviamente c'è un livello di complessità in cui le cose si trasformano in un guazzabuglio, ma usare lo strumento giusto per il lavoro - anche se questo significa strumenti diversi per lavori diversi - può semplificare le cose.

Problemi correlati