.
Annunci online

alessioricco
producer, consumer, crèpes
TECNOLOGIE
13 novembre 2007
[news] do androids eat spaghetti ?
The Android Developer Challenge is open to individuals, teams of individuals, and business entities. While we seek to make the Challenge open worldwide, we cannot open the Challenge to residents of Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) because of U.S. laws. In addition, the Challenge is not open to residents of Italy or Quebec because of local restrictions.

per saperne di piu' ecco le faq

Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. google android

permalink | inviato da alessioricco il 13/11/2007 alle 15:37 | Leggi i commenti e commenta questo postcommenti (3) | Versione per la stampa
24 ottobre 2007
[lampadine] Non è mio, ma lo faccio mio

Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. marketing utopie

permalink | inviato da alessioricco il 24/10/2007 alle 14:46 | Leggi i commenti e commenta questo postcommenti (3) | Versione per la stampa
TECNOLOGIE
18 ottobre 2007
[link] BugNet
 http://www.bugnetproject.com/

BugNET is an issue tracking and project issue management solution built using the ASP.NET web application framework. Email notifications, reporting and per project configuration of fields and values allows efficient management of bugs, feature requests, and other issues for projects of any scale.




permalink | inviato da alessioricco il 18/10/2007 alle 18:39 | Leggi i commenti e commenta questo postcommenti (1) | Versione per la stampa
17 ottobre 2007
[codice] [tips] precalcolare fa bene alla salute
Supponiamo di avere una applicazione che abbia tre colonne, in una ho un elenco di regioni, se clicco su una regione nella seconda colonna ho un elenco di province e cliccando su una provincia ho l'elenco dei comuni di quella provincia.

Ovviamente regioni, province e comuni sono tutti nel loro bel database.

Ci sono tre strade:
La piu' ovvia è quella di fare tre pagine dinamiche che interrogano il db e chiedono di volta in volta l'elenco delle regioni, province e comuni in base ad un parametro di ingresso.

pro:
  • è semplice e naturale
  • permette di cambiare facilmente il template grafico
  • è veloce da scrivere e da manutenere
contro:
  • troppe interrogazioni al db per avere sempre gli stessi risultati

la seconda invece fa si che le pagine dei comuni e delle province siano tutte precalcolate. In genere questa è la fase successiva alla precedente, data la pagina che genera dinamicamente le province, mi creo le 100 e passa pagine statiche, una per provincia. Analogamente per i comuni.

pro:
  • non interrogo il db
  • la pagina viene restituita piu' velocemente
  • non ho parametri nelle pagine (riduco la possibilità di fare sql injection)
contro:
  • se uso dei template grafici che che cambiano spesso, questa soluzione non va bene
l'ultima strada è intermedia ed è valida quando il livello di presentazione del nostro sito è variabile e quindi non posso precalcolarmi la pagina. In pratica per non interrogare il db posso precalcolarmi l'elenco di comuni e province ad esempio sotto forma di files xml o binari (dipende un po' dall'algoritmo che voglio usare) e poi deserializzarli per applicarli al livello di presentazione.

pro:
  • non interrogo il db
  • posso continuare ad utilizzare il template engine

contro:

  • non è performante come la soluzione precedente

 


Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. web code snippets

permalink | inviato da alessioricco il 17/10/2007 alle 17:49 | Leggi i commenti e commenta questo postcommenti (2) | Versione per la stampa
16 ottobre 2007
[codice] [tips] Gestione centralizzata dei parametri nelle URL
Anche se il termine globale e locale è usato in modo improprio, rende bene il concetto di parametri che vengono passati nelle URL e che vengono utilizzati in gran parte delle pagine della nostra applicazione e parametri che vengono utilizzati solo in poche (o addirittura una) pagine.

Una buona regola è quella di gestire i parametri utilizzando una sola funzione il cui codice è condiviso da tutta l'applicazione e che abbia come scopo, per ogni possibile parametro di ingresso ammissibile dall'applicazione, quello di:

  • verificare se il parametro esiste oppure no e impostare il relativo valore di default, se necessario
  • verificare se il tipo che ci aspettiamo dal parametro è quello giusto
  • accedere al dbms per prendere quelle informazioni che nel 90% dei casi dobbiamo andare a prendere ogni volta che quel parametro è settato.
i vantaggi di questa metodologia sono i seguenti:
  • si evitano inutili ripetizioni di codice e copia-incolla suscettibili di bug
  • si ha un unico punto centralizzato che gestisce i parametri di ingresso, cosa che rende estremamente piu' semplice e immediata la manutenzione del codice.
Lo svantaggio piu' evidente è che viene eseguito del codice anche quando non è necessario.

Tag inseriti dall'utente. Cliccando su uno dei tag, ti verranno proposti tutti i post del blog contenenti il tag. asp.net spaghetti code

permalink | inviato da alessioricco il 16/10/2007 alle 17:46 | Leggi i commenti e commenta questo postcommenti (0) | Versione per la stampa
sfoglia
ottobre