Che gestionale immobiliare usate?

[od1n0]

Mah, a me paiono novelle.

Palese che quando si parte in un progetto ci sia l'analisi, ma scsate, ci sono davvero migliori alternative all'xml?



Se conosci l'xml dovresti vedere i link nella pagina e l'xsd... ma si parla con agenti o con tecnici?



Se si parla con tecnici basta indicare quella pagina, se si parla con agenti quella pagina non devi nemmeno indicarla.. per capirsi.



Quindi discutere su questo è tempo perduto.



Secondo: qualcuno era mai riuscito a creare uno standard tra i vari xml usati nel mondo dell'intescambio di informazioni immobiliari?



NO, solo una associazione poteva riuscirci, se ci pensava



terzo: avendo uno standard di fatto, è possibile pensare a altri sviluppi?



Certo, ma solo se hai raggiunto lo step sopra, che è l'ostacolo più grande.



Quarto: l'analisi è inutile quando chi comanda ci mette lo zampino senza conoscerla ne considerarla... se tu hai fatto una cosa considerando alcune dinamiche, ma nel frattempo altri cambiano il tutto, non raggiungi nulla.



ES.



Se io faccio in modo che tutti i gestionali siano compatibili con il cercacasa, pensando anche alla condivisione (ho gestionale->mando dati al cc-> posso condividere anche con chi ha altro gestionale), e il direttore del progetto (Mezzetti) IMPEDISCE, la condivisione negli annunci importati perchè, parole sua, "non esiste condivisione tra piattaforme differenti"... prima mi cascano le palle poi ... è proprio perchè non esiste che si è fatto!



Il progetto considera anni di esperienza nel campo



Si traduce in poche parole in

1)il 60-70% degli agenti non usa un gestionale.

2)Le informazioni devono esser tutte della categoria,

3) I partnres terzi devono darci servizi, non gestire le nostre informazioni.



quindi:



1) devo far venire voglia di usare gestionale: mi aiuta la necessita di fare export sui portali, e la sensibilità verso il mondo della promo in rete.



2) devo rendere la piattaforma compatibile in-out con i gestionali



3) devo prevedere alcune cose che i partenrs commerciali non possono fare



sol.uzioni



1) creo un gestionale gratuito dentro la piattaforma, minimale. (fatto)



2) mi metto in contatto con i veri gestori e creo le condizioni. (fatto al 50%, manca bidirezionalità, richieste-rubrica-tempo)



3) creo sistemi di condivisione tra piattaforme differente: ognuno ha il gestionale che gli piace ma può creare circuiti mls anche con chi ne ha differenti, senza fatica.



4) faccio formazione sul territorio.



Chiaro che ci sono molti altri punti e progetti ma questa è la base.





Chi dice che l'agente dovrebbe fare l'agente ecc. non mi trova concorde.



Il mondo della rete e dell'informatica non è un mondo iniziatico, le cose si posson fare bene affidandosi a professionisti, anzi, io direi MEGLIO.



Nel mio gestionale ho servizi che i gestionali commerciali si sognano o non hanno nemmeno pensato quallo che non c'è non c'è perchè io non ce lo voglio mettere



I partners commerciali ci devono essere, am devono capire che il loro valore è nel servizio, l'interazione, la visibilità...STOP.



La bi-direnzionalità, ad esempio, nel caso di gestionali, garantisce che quando uno vuole usare un gestionale commerciale o migrare verso un altro può farlo agevolmente, con minima perdita e minore impatto possibile... io apro il mondo dei gestionali a chi non lo ha mai calcolato, con il gestionale "gratuito" poi questi può deventare un tuo cliente... o il cliente di un altro... chiaro che si deve abbandonare la fidelizzazione forzata, cioè quella basata sui dati, e abbracciare quella del "servizi sempre migliori"...



Se si allargano diventano dannosi per noi, quindi vanno evitati o gli deve esser impedito di fare alcune pratiche con i nostri dati, siano essi dati "falsati o incompleti" (annunci?) che dati buoni ..

Fine OT



PS.



Se qualcuno ha idee migliori, le può esporre e magari, realizzarle, io sono grato ... per quanto mi riguarda non ho individuato percorsi migliori e sopratutto c'ho messo anni per arrivare qua (dal 2007 che questo progetto esiste, se fosse stato fatto allora si era avanti, ma Giacomello disse che era privo di progettualità )

Ci possono essere modi diversi e piu' performanti per trasportare dati dipende molto dal contesto applicativo. Ad esempio per i servizi restful si usa il json che e' piu' leggero invece di xml che e' piu' pesante. L'xsd che hai indicato non e' una specifica formale e' solo un xsd che non risolve alcune ambiguità. Ad esempio l'elemento <xs:element name="stato" type="xs:int" minOccurs="1"/> mi dice solo che minimo deve esserci una volta nulla mi dice sul valore che puo' assumere l'intero stato e sul suo significato che appunto deve essere esplicato formalmente da qualche altra parte se l'obiettivo e' stabilire uno standard. Quello che manca e' l'identificazione del modello dati formale che vuoi trasportare e le loro relazioni senza ambiguità.

 

[Ponz]

Forse non ci siamo capiti: il json sarebbe sicuramente una alternativa, ma di solito ha applicazioni differenti.. poi quando si fa una analisi si calcola anche l'impatto che hai nel mondo nel quale entri: se tutti parlano arabo, andarci con l'inglese non è sempre una scelta azzeccata... (avendo parlato con diverse decine di partners commerciali ho incontrato SOLO uno che usava il csv con codifica spagnola, gli altri tutti xml utf8).

Prova a proporre json nell'intersambio di dati (a volte enormi quantità di dati) a piattaforme sviluppate su basi o framework vecchi di qualche anno... che scambiano da sempre con xml


Quindi l'evoluzione non porta vantaggio: scartare.

Per gli errori nella documentazione (che vedo hai trovato), ci sono, putroppo sono stati indicati, ma qui entrano in gioco altre problematiche che non sto a spiegarti perchè esulano dal mondo tecnico (ma son reali e son quelle con le quali si deve fare i conti quando si realizza davvero qualcosa)

Manca il modello e l'identificazione delle ambiguità... esempio concreto, hai visto la documentazione oltre all'xsd? C'è la spiegazione nodo per nodo... (anche se temo non aggiornata del tutto , spero lo abbiano fatto )

Comunque, di fatto quella pagina (e gli allegati) ha tutto quel che serve a un tecnico per fare l'xml (in teoria, salvo errori o omissioni o mancanza di aggiornamenti) compreso il parser di verifica.

Quindi discutere di quel che già esiste, che funziona, che è anche più completo di molte realtà commerciali, ha senso per qualcuno che vuole davvero realizzare qualcosa?

 

[ludovica83]

Ludovica.. ti pare di aver aiutato nella comprensione del tema?

La mia è una risposta da bar? Nel caso tu non alimentarla

Non scendere in polemiche inutili e personali anche tu... riflettici... ora possiamo tornare a parlare del tema e non di Ponz?

Ps.

la documentazione tecnica è nella pagina indicata 20 post (dei quali 10 inutili) fa...

Grazie Ponz, questa è la risposta cercata... le specifiche
http://cercacasa.it/docs/Guida importazione cercacasa.pdf

 

[Ponz]

Esatto

Grazie Ponz, questa è la risposta cercata... le specifiche
http://cercacasa.it/docs/Guida importazione cercacasa.pdf

infatti è ben visibile... (proprio sopra il link dell'xsd, se scarichi quello...)

Ma il fatto di pensar che manchino in un progetto così articolato, chiedo scusa, non assomiglia a quello che apre la portiera del prototipo e discute se c'è stato messo il motore o chiede se si è calcolato che deve avere le ruote?

Sull'xml ancora: perfino google non usa json per questo tipo di progetti, ai tempi in cui c'era la piattaforma che mappava gli immobili (solo per mercato usa) il formato indovinate qual'era?

forse non ha fatto bene la progettazione?

 

[od1n0]

Esatto









infatti è ben visibile... (proprio sopra il link dell'xsd, se scarichi quello...)



Ma il fatto di pensar che manchino in un progetto così articolato, chiedo scusa, non assomiglia a quello che apre la portiera del prototipo e discute se c'è stato messo il motore o chiede se si è calcolato che deve avere le ruote?



Sull'xml ancora: perfino google non usa json per questo tipo di progetti, ai tempi in cui c'era la piattaforma che mappava gli immobili (solo per mercato usa) il formato indovinate qual'era?



forse non ha fatto bene la progettazione?

Che si a ben visibile puo' essere ma chiamarla guida all'importazione e' un titolo se permetti ambiguo

Ti stai focalizzando sul contenitore di trasporto e non sul contenuto. Poi cercare di fare l'assunto che se usi xml la progettazione e' necessariamente ben fatta mi sembra azzardato come del resto non e' vero il contrario

Per quel che concerne google usa quello che gli fa piu' comodo.

ad esempio https://developers.google.com/gdata/docs/json

Comunque non ho minimamente contestato il contenitore di trasporto ho solo detto che non e' l'unico o il piu' perfetto per tutte le situazioni ma la valutazione dei pro e dei contro dipende dal contesto applicativo senza entrare nel merito.


Tornando invece al discorso iniziale visto che li e' specificato il trasporto solo di annunci immobiliari in sostanza e' solo quello il modello dati che interessa trasportare fra un gestionale e un altro?

 

[ludovica83]

Grazie Ponz, questa è la risposta cercata... le specifiche
http://cercacasa.it/docs/Guida importazione cercacasa.pdf

Esatto




infatti è ben visibile...

Ma il fatto di pensar che manchino in un progetto così articolato, chiedo scusa, non assomiglia a quello che apre al portiera del prototipo e discute se c'è stato messo il motore o calcolato che deve avere 4 ruote?

"Guida importazione"
Facevi prima a dare i due link, sono + chiari di 1000 post.
[Cmq indipendente da...fatto da chi... con qualche problemino (es. flessibilità degli attributi), non si può dire che manchi di quella che tu chiami progettazione]

 

[Ponz]

"Guida importazione"
Facevi prima a dare i due link, sono + chiari di 1000 post.
[Cmq indipendente da...fatto da chi... con qualche problemino (es. flessibilità degli attributi), non si può dire che manchi di quella che tu chiami progettazione]

Cioè ti stai lamentando perchè io ti ho dato tutto ma non ti ho detto cosa fare passo per passo?

Se ti approcci come "esperto" uno si rivolge a te come tale...

(es. flessibilità degli attributi)

Continuai a sottovalutare

Specie quando tali specifiche vengono da chi ha programmato in java, si DEVE esser rigidi.

in fase di parsing però... siamo stati attenti a valutare i soliti errori e casistiche (es. '.' invece di ',') , che io ben conosco occupandomi della questione da anni .. ma ciò non deve far dire a chi manda i dati "tanto risistemano loro" perchè se voglio creare uno standard non ci devono esser storture ed errori che a cascata creano drammi...

Chiaro che il tutto è "vivo" e quindi sottostà a cambiamenti in itinere che vengono anche dalle interazioni tra soggetti e esigenze differenti... rendendole però poi, di fatto, a disposizione di tutti... se ti pare poco in un mondo caotico, l'aver unificato il tutto...

Quindi io (parser) sono elastico ma ti segnalo... (gli errori bloccanti sono stati ridotti al minimo indispensabile).

Per favore, invece di fare le gare e cercare falle in quel che si è fatto presupponendo quindi che altri non ci abbiano pensato... qualche idea o azione concreta?

Tutto è migliorabile (e quello ancora di più), ma per farlo si deve vere coscienza di quel che c'è altrimenti si discute inutilmente ... e si deve avere anche la capacità di capire che se c'è un XML finito, ci sarà anche il resto

Ci rendiamo conto che si discute più di cercare di trovar difetti in qualcosa, senza conoscerlo, che del tema o di cose utili?

Io quando non so qualcosa, chiedo, non presumo.

Torno a dire: si pensa davvero che un progetto che esiste e funziona non abbia passato quelle che sono fasi ovvie di ogni progetto?

Non è polemica?

 

[Ponz]

Che si a ben visibile puo' essere ma chiamarla guida all'importazione e' un titolo se permetti ambiguo

Eh.. vero...

Ti stai focalizzando sul contenitore di trasporto e non sul contenuto. Poi cercare di fare l'assunto che se usi xml la progettazione e' necessariamente ben fatta mi sembra azzardato come del resto non e' vero il contrario

E quindi... osservazione utile ai fini pratici?

Per quel che concerne google usa quello che gli fa piu' comodo.

google usa praticamente TUTTO non solo google usa json, io lo uso continuamente con ajax

MA anche google, quando creò la piattaforma (oggi non se ne trova più nemmeno traccia) di mappatura delle offerte immobiliari usò l'xml.

mi domando perchè non usi il json, ad esempio, per la mappatura dei siti... pur avendola prevista suggerisce l'xml... errore di progettazione?

Progettare significa non solo scegliere aprioristicamente una tecnologia, ma anche calcolare quanto questa sia diffusa nel contesto e l'impatto che ha cambiarla.

Quindi, per finire la polemica, ad oggi, nel mondo degli annunci o delle informazioni immobiliari MONDIALE, l'xml è lo standard preferito.

Se si fa per chiaccherare e filosofeggiare, ditelo, che vi lascio

 

[Ponz]

Tornando invece al discorso iniziale visto che li e' specificato il trasporto solo di annunci immobiliari in sostanza e' solo quello il modello dati che interessa trasportare fra un gestionale e un altro?

Ecco questo è interessante.. lo sviluppo ulteriore che avevo in mente io, una volta creato una bidirezionalità di linguaggio, era proprio basato sull'interscambio in tempo reale di dati (quindi anche json ) ..

L'idea era:

Se io ho creato, di fatto una bi-direzionalità dei dati ho fatto sì che tutte le piattaforma conoscessero il linguaggio (divenuto standard) e potesser processarlo, in quel caso avremmo potuto pensare a un interscabio anche in tempo reale di dati, come ad esempio risposte a query o altro tipo di servizi, che permettessero, grazie alla centralità del cercacasa, di superare uno dei limiti più grandi nella condivisione: l'utilizzo di piattaforme differenti.

Le mls hanno il "difetto" di esser piattaforme spesso diverse da quella dove l'agente l'avora (il gestionale) a me sarebbe piaciuto, piano piano, di eliminare questo limite, in pratica:
1) uno utilizza il gestionale che vuole, a sua scelta

2) questi è in collaborazione con colleghi, che però hanno gestionali differenti.

Ad oggi per collaborare i due devono fare doppio lavoro, cioè ripetere ad esempio la ricerca su entrambe le piattaforme, il gestionale e l'mls.

Ciò è uno dei primari difetti delle mls, le mls che funzionano hanno spesso un gestionale che è anche l'mls, ottimizzando tempi di lavoro e sopratutto facendo vedere all'operatore sempre l'interezza di risultati.

Quindi ho immaginato che una volta che la maggior parte dei dati fossero risiedenti nel cercacasa (della categoria) questi dati potevano esser serviti tramite web services che rispondessero a delle query...

ecco che il nostro:

1) usa il gestionale che vuole

2) quando fa incroci o ricerche vede sia i dati residenti che i dati altrui, grazie all'integrazione di questo servizio.
3) anche le interazioni vengon trasmesse bi-direzionalmente (quindi ad esempio l'esito di un appuntamento su un immobile non mio appare anche sul gestionale del collega, che lo presenterà al cliente assieme al suo report di attività---)

Solo uno dei possibili sviluppi dell'accentramento di informazioni... ma è roba avanti

Solo noi possiamo attivare questo tipo di iniziative (o altre che non racconterò) perchè non siamo soggetti commerciali, ma i fruitori stessi... quindi i gestionali non hanno quel conflitto con noi che avrebbero tra loro... anzi... gli si apre un mondo dove posson misurarsi sui servizi e le differenze...

 

[od1n0]

Eh.. vero...









E quindi... osservazione utile ai fini pratici?







google usa praticamente TUTTO non solo google usa json, io lo uso continuamente con ajax



MA anche google, quando creò la piattaforma (oggi non se ne trova più nemmeno traccia) di mappatura delle offerte immobiliari usò l'xml.



mi domando perchè non usi il json, ad esempio, per la mappatura dei siti... pur avendola prevista suggerisce l'xml... errore di progettazione?



Progettare significa non solo scegliere aprioristicamente una tecnologia, ma anche calcolare quanto questa sia diffusa nel contesto e l'impatto che ha cambiarla.



Quindi, per finire la polemica, ad oggi, nel mondo degli annunci o delle informazioni immobiliari MONDIALE, l'xml è lo standard preferito.




Se si fa per chiaccherare e filosofeggiare, ditelo, che vi lascio

Torno a ripetere usare xml o altro come formato e' relativo per quel che mi riguarda e non ho detto che sia giusto o sbagliato usarlo ma che dipende da valutazioni fatte rispetto al contesto applicativo. Mi pare di essere stato chiaro quindi e' inutile che insisti con il confronto json xml.Json l'ho portato a esempio per chiarire questo concetto non per contrapporlo in termini di bontà della scelta a xml.

Per quel che concerne l'utilizzo che fai di tecniche ajax centra poco.....

Per quel che riguarda gli errori di progettazione ci possono essere a prescindere dalla scelta del formato di trasporto dati scelto (NON HO DETTO CHE CI SONO).


Quello che ti ho chiesto invece e' un'altra cosa senza fare polemiche che tu vedi dove non ci sono.
Ovvero
"Tornando invece al discorso iniziale visto che li e' specificato il trasporto solo di annunci immobiliari in sostanza e' solo quello il modello dati che interessa trasportare fra un gestionale e un altro?" per evitare la dipendenza dai vari gestionali che sarebbe il tuo sogno.