Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #21661 > unrolled thread

Consigli per costruzione sito social-commerciale

Back to article view | Back to it.comp.www.php

Contents

  Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-21 22:03 +0200
    Re: Consigli per costruzione sito social-commerciale Leonardo Serni <lserni@gmail.com> - 2017-08-21 23:26 +0200
    Re: Consigli per costruzione sito social-commerciale fmassei@gmail.com - 2017-08-21 14:57 -0700
      Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-23 14:08 +0200
        Re: Consigli per costruzione sito social-commerciale Alessandro Pellizzari <shuriken@amiran.it> - 2017-08-23 14:29 +0100
          Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-23 21:38 +0200
            Re: Consigli per costruzione sito social-commerciale fmassei@gmail.com - 2017-08-24 00:36 -0700
        Re: Consigli per costruzione sito social-commerciale fmigliori <fmigliori@gmail.com> - 2017-08-23 07:34 -0700
          Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-24 14:51 +0200
            Re: Consigli per costruzione sito social-commerciale fmigliori <fmigliori@gmail.com> - 2017-08-24 06:34 -0700
              Re: Consigli per costruzione sito social-commerciale Alessandro Pellizzari <shuriken@amiran.it> - 2017-08-24 14:47 +0100
                Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-25 14:49 +0200
              Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-25 14:38 +0200
                Re: Consigli per costruzione sito social-commerciale Alessandro Pellizzari <shuriken@amiran.it> - 2017-08-25 14:13 +0100
                Re: Consigli per costruzione sito social-commerciale fmigliori <fmigliori@gmail.com> - 2017-08-25 09:05 -0700
                  Re: Consigli per costruzione sito social-commerciale Alessandro Pellizzari <shuriken@amiran.it> - 2017-08-25 17:15 +0100
                Re: Consigli per costruzione sito social-commerciale "go_brexit_go" <21669invalid@mynewsgate.net> - 2017-08-29 14:52 +0000
                  Re: Consigli per costruzione sito social-commerciale fmassei@gmail.com - 2017-08-29 09:04 -0700
                    Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-29 22:32 +0200
                      Re: Consigli per costruzione sito social-commerciale fmassei@gmail.com - 2017-08-29 14:29 -0700
                        Re: Consigli per costruzione sito social-commerciale "go_brexit_go" <21669invalid@mynewsgate.net> - 2017-08-30 14:43 +0000
                          Re: Consigli per costruzione sito social-commerciale fmassei@gmail.com - 2017-08-30 08:50 -0700
                          Re: Consigli per costruzione sito social-commerciale GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2017-08-31 10:08 +0200
                      Re: Consigli per costruzione sito social-commerciale "go_brexit_go" <21669invalid@mynewsgate.net> - 2017-08-30 14:38 +0000
    Re: Consigli per costruzione sito social-commerciale "go_brexit_go" <21669invalid@mynewsgate.net> - 2017-08-23 17:09 +0000

Page 1 of 2  [1] 2  Next page →

#21661 — Consigli per costruzione sito social-commerciale

Salve,

non sarò io a farlo ma dovendo affidarmi a terzi vorrei prima di tutto 
avere le idee chiare io anche grazie ai Vostri consigli! :)

Il sito sarà una sorta di social legato al mondo commerciale, 
ipotizziamo di creare uno spazio dove gli utenti possano condividere i 
propri gusti commerciali ad esempio le marche e le tipologia di pasta 
che mangiano, quante volte etc.

Step successivo i produttori potranno gestire i loro prodotti ed infine 
anche coloro che li vendono potranno inserire i loro punti vendita.

Morale della favola pensavo ad un ambito L.A.M.P., essendo un utente 
Debian da anni per me il webserver è solo ed esclusivamente Linux!

Entrando nel merido del db pensavo di farne creare due distinti uno 
legato ai prodotti con un accesso tipo backpanel per i produttori, i 
venditori e l'admin in modo che il cuore del sistema ovvero i prodotti 
siano "al sicuro" e di veloce accesso e l'altro social per gli utenti 
finali che dialogherà con il db prodotti.

Saluti!
GabrieleMax

[toc] | [next] | [standalone]

#21662

On Mon, 21 Aug 2017 22:03:59 +0200, GabrieleMax <gabriele1NOSPAM@hotmail.com>
wrote:

>Entrando nel merido del db pensavo di farne creare due distinti uno 
>legato ai prodotti con un accesso tipo backpanel per i produttori, i 
>venditori e l'admin in modo che il cuore del sistema ovvero i prodotti 
>siano "al sicuro" e di veloce accesso e l'altro social per gli utenti 
>finali che dialogherà con il db prodotti.

Il database è uno: non è che ottieni granché mettendocene due, se non parecchi
grattacapi :-)

Come progettare il DB dovrà dirlo il DB Admin, dopo avere discusso a lungo con
qualcuno che abbia familiarità con la lista dei requisiti e le 'user stories',
per esempio "Sono il produttore della Pasta Pista, entro nel sito, vedo questo
e faccio quello", oppure - e questo è parecchio più importante - "sono l'umile
utente, mi collego al sito, cosa vedo? Cosa faccio - e come? E perché mi potrà
piacere farlo?".

Dal fatto che se ti piace la Pizza Pazza probabilmente ti interesserà sapere i
punti vendita nei dintorni discenderà la necessità di collegare le tabelle dei
punti vendita e quella dei prodotti (magari georeferenziare i PV - e qualsiasi
utente sarebbe interessatissimo a vedere i prezzi nei vari punti vendita, cosa
che sospetto i venditori non apprezzeranno più di tanto <grin>).

Ma sono tutte cose che devono venire fuori dalla fase di analisi, che non devi
fare tu, se no credi che le cose finiranno male :-). BTDTGTTS, come si dice.

Di database ne userai sicuramente due: ma perché uno è quello di produzione, e
uno è quello di staging dove farai i test - per esempio simulando un carico di
clienti bello péso, per vedere cosa fanno i tempi di risposta.

Leonardo e i suoi 0.02 EUR
-- 

A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916

[toc] | [prev] | [next] | [standalone]

#21663

On Monday, August 21, 2017 at 4:04:01 PM UTC-4, GabrieleMax wrote:
> Il sito sarà una sorta di social legato al mondo commerciale, 
> ipotizziamo di creare uno spazio dove gli utenti possano condividere i 
> propri gusti commerciali ad esempio le marche e le tipologia di pasta 
> che mangiano, quante volte etc.
> Step successivo i produttori potranno gestire i loro prodotti ed infine 
> anche coloro che li vendono potranno inserire i loro punti vendita.
> 

Lascia stare. Questa "idea" l'ho sentita centinaia di volte, ed è sempre
finita male, per centinaia motivi che non ti sto qui a dire (ma a cui
penso puoi arrivare anche te).

Invece di pensare a come far fare a un esperto (che quindi non ha bisogno
di un tuo parere "a sensazione") un lavoro inutile, mi concentrerei sullo
stilare uno studio di fattibilità. Risparmi soldi, tempo e fatica.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21664

> Lascia stare. Questa "idea" l'ho sentita centinaia di volte, ed è sempre
> finita male, per centinaia motivi che non ti sto qui a dire (ma a cui
> penso puoi arrivare anche te).
> 
> Invece di pensare a come far fare a un esperto (che quindi non ha bisogno
> di un tuo parere "a sensazione") un lavoro inutile, mi concentrerei sullo
> stilare uno studio di fattibilità. Risparmi soldi, tempo e fatica.

Ti ringrazio per questo tuo commento, effettivamente quando si hanno 
delle idee che comportano un'esposizione economica è sempre bene 
rimanere con i piedi per terra!

Di mio posso dirti che almeno inizialmente parte del lavoro potrei 
farmeli con calma "in casa", ho iniziato a fare siti web nel lontano 
1996, ovvio oggi molto anzi moltissimo è cambiato però non sono 
completamente digiuno, non dovrei partire da zero!

A dirla tutta ho già creato la grafica quindi logo e bottoni oltre al 
databse sql che devo ottimizzare in base alle query, ho già strutturato 
su carta tutti i ruoli e le funzionalità delle tre tipologie di utenti e 
per ora l'unica bega in termini economici sarebbe il disclamer da far 
scrivere ad un legale.

Potrà funzionare? Potrà non funzionare? Di Zuckemberg ce n'è uno e tutti 
gli altri son nessuno? Chissà... una mia amica diceva che se non miri a 
qualcosa non colpirai mai nulla!

> Ciao!

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21665

On 23/08/2017 13:08, GabrieleMax wrote:

> Potrà funzionare? Potrà non funzionare? Di Zuckemberg ce n'è uno e tutti 
> gli altri son nessuno? Chissà... una mia amica diceva che se non miri a 
> qualcosa non colpirai mai nulla!

Ti auguro buona fortuna, ma tieni conto che facebook ha iniziato a 
guadagnare qualcosa dopo che ha passato il miliardo di utenti, mentre 
snapchat sta collassando nonostante fosse "il social network del 
futuro", e twitter fatica a stare a galla.

La prima domanda che dovresti farti è: "perchè gli utenti dovrebbero 
usare il mio social invece degli altri?", subito seguita da "e quanti 
utenti posso sperare di avere?"

Bye.

[toc] | [prev] | [next] | [standalone]

#21668

> Ti auguro buona fortuna, ma tieni conto che facebook ha iniziato a 
> guadagnare qualcosa dopo che ha passato il miliardo di utenti, mentre 
> snapchat sta collassando nonostante fosse "il social network del 
> futuro", e twitter fatica a stare a galla.

Si ho seguito quelle vicende, diciamo che quelli sono social network 
nudi e crudi nel senso partono dal voler "ammaliare" e tirar dentro gli 
utenti per poi rivendere visibilità/pubblicità al raggiungimento di un 
certo numero degli stessi!

Nel mio caso volevo da subito tirar dentro tipo vetrina ma non solo la 
parte commerciale e rendere il tutto social, detto cosi' può sembrar 
banale ma ho già strutturato tutti i ruoli degli uni e degli altri.

> La prima domanda che dovresti farti è: "perchè gli utenti dovrebbero 
> usare il mio social invece degli altri?", subito seguita da "e quanti 
> utenti posso sperare di avere?"

Di fatto parte con l'idea di utility che "nasconde" anche un'aspetto 
social e commerciale per i produttori.

> Bye.

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21669

On Wednesday, August 23, 2017 at 3:39:00 PM UTC-4, GabrieleMax wrote:
> Nel mio caso volevo da subito tirar dentro tipo vetrina ma non solo la 
> parte commerciale e rendere il tutto social, detto cosi' può sembrar 
> banale ma ho già strutturato tutti i ruoli degli uni e degli altri.
> 
> <snip>
>
> Di fatto parte con l'idea di utility che "nasconde" anche un'aspetto 
> social e commerciale per i produttori.
> 

Ripeto, e lo dico per te: è 'na ca**ata.

Non bisogna pensare: fai uno studio sui potenziali clienti, quelli che
ti danno il cash. Non si tirano su businesses tanto per fare, solo perché
c'è un'idea, si tira su un'attività perché c'è un qualche tipo di
domanda. E' la ca**o di base.

Anche tu fossi nella condizione di non doverti preoccupare dei soldi,
pensa al tuo tempo: potresti impiegarlo in cose assai più prolifiche.

Se poi vuoi andare avanti oh, in bocca al lupo.
Però la mia risposta alla tua domanda iniziale rimane uguale.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21666

Ora mi è chiaro, non sarai te a farlo, ma bensì sarà fatto da te. Ma dillo 
subito che stai parlando del tuo progetto nel cassetto!

> Entrando nel merido del db pensavo di farne creare due distinti uno 
> legato ai prodotti con un accesso tipo backpanel per i produttor

la scelta è dovuta dal diverso utilizzo che ne fai?

Tipo rdbms da una parte perché ti serve consistenza, 
NoSql dall'altra perché deve essere veloce?

O è lo stesso dbms e usi due db semplicemente per separare le tabelle?
se usi rdbms che li supportano
puoi usare gli schemi. Mysql non li usa ma permette join tra db diversi. 
Però per fare una cosa del genere ci vuole un motivo preciso che non 
sia 'fatture da una parte, preventivi dall'altra che così è ordinato'.

Te lo chiedo perché anche se lo hai scritto, non ho capito.

> i prodotti  siano "al sicuro" e di veloce accesso e l'altro social per gli utenti 
> finali che dialogherà con il db prodotti. 

Non mi è chiaro. Uno "al sicuro" e di veloce accesso l'altro insicuro e di 
accesso lento?
I dati degli utenti in un database insicuro? ma sei sicuro?
Come pensi di differenziare le caratteristiche due db?
sono gestiti da due dbms diversi?
sono in due macchine diverse?

Ma soprattutto: cosa intendi per sicuro?

Ciao e buon lavoro

[toc] | [prev] | [next] | [standalone]

#21670

> la scelta è dovuta dal diverso utilizzo che ne fai?

La scelta ipotetica e da non esperto di db del voler percorrere la 
strada di due db separati è legata solamente al traffico che si potrebbe 
generare per cui il dividere in maniera netta la parte social dalla 
parte commerciale/prodotti permetterebbe imho di non "rallentare" 
l'accesso degli uni e degli altri ma ribadisco le mie solo solo ed 
esclusivamente ipotesi e pensieri!

> Tipo rdbms da una parte perché ti serve consistenza,
> NoSql dall'altra perché deve essere veloce?

Da valutare la scelta di due "tecnologie" separate, io preferirei usare 
la stessa per entrambi.

> O è lo stesso dbms e usi due db semplicemente per separare le tabelle?
> se usi rdbms che li supportano
> puoi usare gli schemi. Mysql non li usa ma permette join tra db diversi.
> Però per fare una cosa del genere ci vuole un motivo preciso che non
> sia 'fatture da una parte, preventivi dall'altra che così è ordinato'.

Come già accennato sopra credo, sottolineo e ribadisco credo che avere 
due situazioni separate permetta ad esempio alla parte commerciale che 
numericamente sarebbe di gran lunga inferiore rispetto alla parte social 
di avere maggior velocità e di non navigare in un mare unico quindi un 
unico db.

> Non mi è chiaro. Uno "al sicuro" e di veloce accesso l'altro insicuro e di
> accesso lento?
> I dati degli utenti in un database insicuro? ma sei sicuro?

Mi sono espresso male io, la divisione in due db riguarderebbe "solo" la 
divisione del traffico.

> Come pensi di differenziare le caratteristiche due db?
> sono gestiti da due dbms diversi?
> sono in due macchine diverse?

Inizialmente non verrebbero gestiti da due macchine diverse e quindi è 
ovvio che il beneficio in termini di traffico nell'avere due db separati 
non ci sarebbero però partendo subito con l'idea di due db diversi il 
posizionamento su due sever diversi diventerebbe una strada percorribile 
nel caso si dovesse rendere necessario!

> Ma soprattutto: cosa intendi per sicuro?

Paradossalmente ma non troppo per sicuro intendo poter all'occorrenza 
instaurare anche una vpn con certificati autoprodotti per la parte 
commerciale quando e se potesse essercene la richiesta in modo da creare 
una parte blindata per il "core business" ovvero i prodotti e lasciare 
la parte aperta al mondo ovvero quella social con ssl.

> Ciao e buon lavoro

Saluti, grazie per il tempo dedicatomi e tengo ancora a precisare che i 
miei sono solo pensieri quindi posso ovvimanente anche aver palesato 
immani cavolate a livello tecnico.

GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21671

Il giorno giovedì 24 agosto 2017 14:51:16 UTC+2, GabrieleMax ha scritto:
> > la scelta è dovuta dal diverso utilizzo che ne fai?
> 
> La scelta ipotetica e da non esperto di db del voler percorrere la 
> strada di due db separati è legata solamente al traffico che si potrebbe 
> generare per cui il dividere in maniera netta la parte social dalla 
> parte commerciale/prodotti permetterebbe imho di non "rallentare" 
> l'accesso degli uni e degli altri ma ribadisco le mie solo solo ed 
> esclusivamente ipotesi e pensieri!
> 
> > Tipo rdbms da una parte perché ti serve consistenza,
> > NoSql dall'altra perché deve essere veloce?
> 
> Da valutare la scelta di due "tecnologie" separate, io preferirei usare 
> la stessa per entrambi.

Pensare a una divisione per permettere in futuro di ubicare una parte dei dati 
in un server apposito è giusta, in questo modo nel momento del cambiamento
il software avrà una necessità molto ridotta se non nulla di aggiornamento. 
Per contro non puoi fare una query con tabelle di due db diversi 
in previsione che siano su macchine diverse.
Il ché è limitante e richiede maggiore programmazione e riduci la scalabilità.

Io, in un progetto sperimentale, lo eviterei, perché se l'idea è davvero 
buona e redditizia dovrai sicuramente farlo rifare da capo da professionisti 
tra cui te nel tuo ruolo abituale (se ti va di risparmiare).

Non ti offendere, ma in solitaria non si possono più creare un certo tipo di sw.
Sono richiesti esperti in grafica (desk e mobile), esperti di usabilità, 
un paio di programmatori lato server, uno per quel troiaio di js, 
consulenze su hw, db...
Guarda quel troiaio immondo di eBay, in realtà una volta ingranato venti anni fa
dovevano buttarlo via e farlo come si deve e invece hanno continuato ad 
aggregare ciarpame su altro ciarpame.

Tornando noi, ti consiglio un solo db, studiati le caratteristiche dei vari 
dbms  relazionali e noslq e poi scegli, da qui un consiglio ce l'avrai sempre.

[toc] | [prev] | [next] | [standalone]

#21672

On 24/08/2017 14:34, fmigliori wrote:

> Guarda quel troiaio immondo di eBay, in realtà una volta ingranato venti anni fa
> dovevano buttarlo via e farlo come si deve e invece hanno continuato ad
> aggregare ciarpame su altro ciarpame.

Hai sollevato un argomento importante.

Se Gabriele è proprio deciso ad andare avanti, allora la proof of 
concept la farei con un singolo DB, senza pensare troppo a prestazioni, 
scalabilità, sicurezza, ecc.

Io, onestamente, andrei su MongoDB perchè è più flessibile, anche se 
"perdi" l'integrità referenziale.

Nel momento in cui la piattaforma ingrana va comunque messo in conto di 
doverla riscrivere. O per intero o pezzo per pezzo.

A quel punto si può iniziare a parlare di architettura: scegliere i DB 
(plurale) in base alle esigenze di ogni componente, scegliere i server, 
il layer di orchestration, il monitoring, le politiche di backup.

È abbastanza inutile pensare a queste cose prima ancora di sapere quanti 
utenti ci saranno, quanto traffico fanno, quante aziende clienti 
potranno accedere, quanti prodotti caricheranno, cosa chiederanno di 
implementare, ecc.

Bye.

[toc] | [prev] | [next] | [standalone]

#21674

> Se Gabriele è proprio deciso ad andare avanti, allora la proof of 
> concept la farei con un singolo DB, senza pensare troppo a prestazioni, 
> scalabilità, sicurezza, ecc.

Si, meglio partire da subito con una sorta di low profile o meglio con 
ciò che serve ora senza spendere in tutti i sensi risorse e tempo per 
qualcosa ora non avrebbe senso e quando e se lo dovesse avere magari 
l'idea di partenza sarebbe comunque da buttare!

> Io, onestamente, andrei su MongoDB perchè è più flessibile, anche se 
> "perdi" l'integrità referenziale.

Come già accennato nel mio piccolo anzi piccolissimo sono sempre andato 
di MySQL e php, dovrei studiarmi, come già consigliato, le varie 
soluzioni a livello di db.

> Nel momento in cui la piattaforma ingrana va comunque messo in conto di 
> doverla riscrivere. O per intero o pezzo per pezzo.

Vero, non avevo pensato a questo "piccolo" particolare! :D

> È abbastanza inutile pensare a queste cose prima ancora di sapere quanti 
> utenti ci saranno, quanto traffico fanno, quante aziende clienti 
> potranno accedere, quanti prodotti caricheranno, cosa chiederanno di 
> implementare, ecc.

Tutto giustissimo!

> Bye.

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21673

> Io, in un progetto sperimentale, lo eviterei, perché se l'idea è davvero
> buona e redditizia dovrai sicuramente farlo rifare da capo da professionisti
> tra cui te nel tuo ruolo abituale (se ti va di risparmiare).

Mi hai dato la giusta chiave di lettura, effettivamente ho visto anch'io 
numerosi siti che con il passare del tempo e nonostante l'avvento di 
nuove tecnologie hanno subito solo rattoppi e non vere e proprie 
rivisitazioni.

> Non ti offendere, ma in solitaria non si possono più creare un certo tipo di sw.
> Sono richiesti esperti in grafica (desk e mobile), esperti di usabilità,
> un paio di programmatori lato server, uno per quel troiaio di js,
> consulenze su hw, db...

Ho già chi mi ha sviluppato un sito di ecommerce in html5 e con 
l'utilizzo di Ajax davvero molto bravi (http://websys.co.in/), avevo chi 
sviluppava app per ios e android ma mi piacerebbe rivolgermi altrove 
(http://www.aegisisc.com/), per la grafica o meglio per la Grafica 
dovrei iniziare una seria ricerca!

Avvalendomi di sviluppatori esteri per fargli capir meglio le mie 
esigenze gli passo già pagine in html e gli creo già il db con i vari 
campi, tipologie di dati etc. e loro mi ottimizzano il tutto in maniera 
seria! :D

> Guarda quel troiaio immondo di eBay, in realtà una volta ingranato venti anni fa
> dovevano buttarlo via e farlo come si deve e invece hanno continuato ad
> aggregare ciarpame su altro ciarpame.

Effettivamente è un "bell'esempio" di cosa non bisognerebbe fare! :D

> Tornando noi, ti consiglio un solo db, studiati le caratteristiche dei vari
> dbms  relazionali e noslq e poi scegli, da qui un consiglio ce l'avrai sempre.

Grazie per il tempo dedicato alle risposte ed anche per tutti i consigli! :)

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21675

On 25/08/2017 13:38, GabrieleMax wrote:

> Mi hai dato la giusta chiave di lettura, effettivamente ho visto anch'io 
> numerosi siti che con il passare del tempo e nonostante l'avvento di 
> nuove tecnologie hanno subito solo rattoppi e non vere e proprie 
> rivisitazioni.

Attento a non confondere quello che vedi con quello che c'è sotto.

Per esempio, mi pare fosse Twitter, ha cambiato tutto il backend almeno 
due volte, passando da Ruby a Java a Scala e da Postgres a Mongo a 
Cassandra (o qualcosa del genere), mantenendo l'interfaccia quasi identica.

Facebook ha scritto una VM apposta (HHVM) e creato un linguaggio (Hack), 
oltre a un framework per il frontend (React) e diverse altre cose.

Se ci fai caso, a ogni minima modifica dell'interfaccia di qualcosa di 
minimamente famoso c'è una sollevazione popolare, con petizioni, 
raccolte firme e campagne di boicottaggio.

Mentre se cambi il DB o il linguaggio di programmazione non se ne 
accorge nessuno.

Ecco perchè preferisco fare il backender che il frontender :P

Bye.

[toc] | [prev] | [next] | [standalone]

#21676

Il giorno venerdì 25 agosto 2017 14:38:31 UTC+2, GabrieleMax ha scritto:

> Ho già chi mi ha sviluppato un sito di ecommerce in html5 e con 
> l'utilizzo di Ajax davvero molto bravi (http://websys.co.in/), avevo chi 
> sviluppava app per ios e android ma mi piacerebbe rivolgermi altrove 
> (http://www.aegisisc.com/), per la grafica o meglio per la Grafica 
> dovrei iniziare una seria ricerca!

Perfetto. Con 2000 euro puoi partire con la tua idea e se funziona: preparati.

Per rimanere in ambito db io in genere uso postgres e mysql perché sono 
belli "legnosi" e mi permettono di avere consistenza (mysql un po' meno). 
I NoSQL hanno proprio la caratteristica di non offrire vincoli alla struttura 
dei singoli record e la consistenza dei dati è demandata al tuo software, 
quindi delirio (non perché lo scrivi te o gli indiani, ma proprio perché è 
facile perdersi per chiunque).
Però in certi compiti è perfetto, perché velocissimo e di conseguenza 
scala bene, basta dargli un bel po' di ram.

L'unica cosa riguarda il "rinunciare alla sicurezza", Alessandro si riferiva 
a una demo. So che lo sai, ma meglio essere ridondanti.

[toc] | [prev] | [next] | [standalone]

#21677

On 25/08/2017 17:05, fmigliori wrote:

> L'unica cosa riguarda il "rinunciare alla sicurezza", Alessandro si riferiva
> a una demo. So che lo sai, ma meglio essere ridondanti.

Vero, mi rendo conto che non ho spiegato bene, e la sicurezza è importante.

Mi riferivo soprattutto al fatto di non mettersi a creare utenti 
separati o DB separati sul DB-server, perchè complicano solo la vita.

Crea un database con un utente (non "root senza password" come di 
default in MySQL :D) e gestisci i permessi lato PHP.

Bye.

[toc] | [prev] | [next] | [standalone]

#21679

GabrieleMax <gabriele1NOSPAM@hotmail.com> ha scritto:

> Ho già chi mi ha sviluppato un sito di ecommerce in html5 e con 
> l'utilizzo di Ajax davvero molto bravi (http://websys.co.in/),

Indiani?! Rivolgersi ad italiani proprio no, eh?!... O_o

> avevo chi 
> sviluppava app per ios e android ma mi piacerebbe rivolgermi altrove 
> (http://www.aegisisc.com/),

"Under Construction" 

Ammappete... O_o

> per la grafica o meglio per la Grafica 
> dovrei iniziare una seria ricerca!

A questo punto, certamente...

> Avvalendomi di sviluppatori esteri per fargli capir meglio le mie 
> esigenze gli passo già pagine in html e gli creo già il db con i vari 
> campi, tipologie di dati etc. e loro mi ottimizzano il tutto in maniera 
> seria! :D

-.-

[toc] | [prev] | [next] | [standalone]

#21680

On Tuesday, August 29, 2017 at 10:52:38 AM UTC-4, go_brexit_go wrote:
> GabrieleMax <gabriele1NOSPAM@hotmail.com> ha scritto:
> 
> > Ho già chi mi ha sviluppato un sito di ecommerce in html5 e con 
> > l'utilizzo di Ajax davvero molto bravi (http://websys.co.in/),
> 
> Indiani?! Rivolgersi ad italiani proprio no, eh?!... O_o
> 

Se la differenza di prezzo a pari qualità gliela paghi te, penso non
obietterebbe a prendere italiani :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#21681

> Se la differenza di prezzo a pari qualità gliela paghi te, penso non
> obietterebbe a prendere italiani :)

Tra 7mila euro e 2mila euro c'è una bella differenza se vuoi, almeno 
inizialmente, semplicemente provarci!

Quando e se il tutto dovesse girare bene è ovvio che mi piacerebbe 
spostare tutto in Italia, tu non sai quanto mi rode il dover 
accompagnare gli amici all'aeroporto perchè partono per andare a 
lavorare all'estero ma pensate a tutte quelle persone a cui viene 
sparata la cifra di 7mila euro, si guardano in tasca e capiscono che 
devono per forza mettere una pietra sopra al proprio "sogno" senza 
nemmeno provarci...

Come già detto di Zuckenberg ce n'è uno solo, è ovvio che la maggior 
parte di chi vorrebbe provarci sarà destinato a chiudere entro un anno 
ma forse anche no! :)

> Ciao!

Saluti.
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21682

On Tuesday, August 29, 2017 at 4:32:28 PM UTC-4, GabrieleMax wrote:
> > Se la differenza di prezzo a pari qualità gliela paghi te, penso non
> > obietterebbe a prendere italiani :)
> 
> Tra 7mila euro e 2mila euro c'è una bella differenza se vuoi, almeno 
> inizialmente, semplicemente provarci!
> 

Infatti, non c'è nemmeno da pensarci!

> Quando e se il tutto dovesse girare bene è ovvio che mi piacerebbe 
> spostare tutto in Italia, tu non sai quanto mi rode il dover 
> accompagnare gli amici all'aeroporto perchè partono per andare a 
> lavorare all'estero ma pensate a tutte quelle persone a cui viene 
> sparata la cifra di 7mila euro, si guardano in tasca e capiscono che 
> devono per forza mettere una pietra sopra al proprio "sogno" senza 
> nemmeno provarci...
> 

Senza contare che probabilmente in Italia si prendono i 7mila, passano
il lavoro in india a 2mila, e l'avanzo se lo tengono senza aver fatto
nulla.


Ciao!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web