Il linguaggio di programmazione PHP
 

Consigli per costruzione sito social-commerciale

GabrieleMax 21 Ago 2017 22:03
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
Leonardo Serni 21 Ago 2017 23:26
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 *****isi, 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
fmassei@gmail.com 21 Ago 2017 23:57
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 stu***** di fattibilità. Risparmi soldi, tempo e fatica.

Ciao!
GabrieleMax 23 Ago 2017 14:08
> 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 stu***** 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
Alessandro Pellizzari 23 Ago 2017 15:29
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.
fmigliori 23 Ago 2017 16:34
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
go_brexit_go 23 Ago 2017 19:09
GabrieleMax <gabriele1NOSPAM@hotmail.com> ha scritto:

> 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.

Hai già scritto cosa fare tu, dove sarebbero i punti su cui
chiedere consiglio?
GabrieleMax 23 Ago 2017 21:38
> 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 ******* 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
b*****e 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
fmassei@gmail.com 24 Ago 2017 09:36
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
> b*****e 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 stu***** 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!
GabrieleMax 24 Ago 2017 14:51
> 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
fmigliori 24 Ago 2017 15:34
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.
Alessandro Pellizzari 24 Ago 2017 15:47
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.
GabrieleMax 25 Ago 2017 14:38
> 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
GabrieleMax 25 Ago 2017 14:49
> 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
Alessandro Pellizzari 25 Ago 2017 15:13
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 ******* ,
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.
fmigliori 25 Ago 2017 18:05
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.
Alessandro Pellizzari 25 Ago 2017 18:15
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.
go_brexit_go 29 Ago 2017 16:52
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

-.-
fmassei@gmail.com 29 Ago 2017 18:04
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!
GabrieleMax 29 Ago 2017 22:32
> 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
fmassei@gmail.com 29 Ago 2017 23:29
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!
go_brexit_go 30 Ago 2017 16:38
GabrieleMax <gabriele1NOSPAM@hotmail.com> ha scritto:

> 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...

Un qualsiasi "sogno" per definizione richiede un impegno da "sogno", appunto.
Altrimenti non è un sogno.
go_brexit_go 30 Ago 2017 16:43
fmassei@gmail.com <fmassei@gmail.com> ha scritto:

> 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!

Voi sembrate essere contrari al motto: "Come spendi, mangi!" :-D

> 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.

Allo stesso modo in india possono prendere i 7 mila e girare il lavoro
sempre in india od in cina a 1000 euro, "e l'avanzo se lo tengono
senza aver fatto nulla". Nessuno può sapere come opereranno...
fmassei@gmail.com 30 Ago 2017 17:50
On Wednesday, August 30, 2017 at 10:43:29 AM UTC-4, go_brexit_go wrote:
> fmassei@gmail.com <fmassei@gmail.com> ha scritto:
>> On Tuesday, August 29, 2017 at 4:32:28 PM UTC-4, GabrieleMax wrote:
>>> Tra 7mila euro e 2mila euro c'Ú una bella differenza se vuoi, almeno
>>> inizialmente, semplicemente provarci!
>>>
>>
>> Infatti, non c'Ú nemmeno da pensarci!
>
> Voi sembrate essere contrari al motto: "Come spendi, mangi!" :-D
>

Se mai è il contrario, sei te che per qualche motivo vuoi pagare 20 euro
un panino col prosciutto.

>> 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.
>
> Allo stesso modo in india possono prendere i 7 mila e girare il lavoro
> sempre in india od in cina a 1000 euro, "e l'avanzo se lo tengono
> senza aver fatto nulla". Nessuno può sapere come opereranno...
>

... ma grazie al meraviglioso mondo di Internet ognuno può cercare,
valutare e mettere sotto contratto chiunque nel mondo, così italiani e
indiani che "rigirano" lavori se la prendono in saccoccia.

Ciao!
GabrieleMax 31 Ago 2017 10:08
> Allo stesso modo in india possono prendere i 7 mila e girare il lavoro
> sempre in india od in cina a 1000 euro, "e l'avanzo se lo tengono
> senza aver fatto nulla". Nessuno può sapere come opereranno...

Come già detto non sono uno sprovveduto in ambito informatico, realizzo
siti internet da quando c'era il modem a 14.4, ovvio oggi è tutta
un'altra storia ci mancherebbe volessi confrontare il web di 22 anni fa
con quello di oggi ma se mi dai dei files in php, un database sql,
qualche script riesco a capire se questi sono fatti male, discretamente
benem, etc. e capisco anche se e quando mi dovessero sparare un prezzo
allucinante semplicemente per una query che tiri su dei dati da una
stupida tabella con 4 campi in croce!

Il motivo per cui io mi "limito" a dirigere i lavori o quantomeno a dare
delle linee guida è perchè non ho materialmente tempo per scrivere le
pagine e almeno inizialmente solo per provarci non ho intenzione di
spendere 7mila euro.

Saluti.
GabrieleMax

Links
Giochi online
Dizionario sinonimi
Leggi e codici
Ricette
Testi
Webmatica
Hosting gratis
   
 

Il linguaggio di programmazione PHP | Tutti i gruppi | it.comp.www.php | Notizie e discussioni php | Php Mobile | Servizio di consultazione news.