Ferrovie On Line

Non riduci un benemerito nulla. Purtroppo Java è stato contaminato da seghe mentali tipiche dei matematici riguardo alla purezza degli oggetti, portando a barocchi alberi ereditari di classi e sottoclassi con classi definite anche vuote "perché fa figo", il solo fatto che string non sia un tipo base la dice lunga sull'effettiva utilità.

Java povera bestia nacque con in mente la portabilità assoluta, che alla fine ha significato soltanto complicare tutto allungando inutilmente la gerarchia di classi per funzionare anche su device senza schermo, senza tastiera, senza mouse o senza nulla (qualcuno ha detto smartcard java?)

Il problema è che NO, NON SERVE PRATICAMENTE MAI che la stessa applicazione giri su una smartcard così come gira su un pc. E' una pura follia mentale quella di far girare le app su dispositivi così diversi, perché non sarà mai una funzione UTILE a nessuna app. Pensa a un word processor, pensa a un media player, apparte quel piccolo nucleo base il 90% del tempo perso a programmarli è tutta interazione con l'utente. Che dovrebbe essere curata fin nei minimi dettagli. Text box ordinate secondo logica per la tabulazione che così non sono. Autofocus di certi controlli alla creazione delle finestre. Tutti dettagli che fanno perdere tempo ma vanno seguiti. La sega mentale (mi si passi il termine) Java è "fregatene". Fai il programma che gira ovunque. E così non è.

Paradossalmente il tanto discusso .NET di Microsoft gira senza grosse pippe mentali su Windows, su Linux e su MacOS X, non c'è da spararsi per gestire una GUI decente, e non c'è nemmeno da andare troppo lontano per usare il resto dei dispositivi di interazione con l'utente.

Senza appunto andare a colpo sicuro, parlando delle risorse richieste dalla JVM

DrWatson, quindi sai che il dove6 mostra una pagina web e che non ha quindi bisogno di log, tanto sei sicuro di poter affermare che salvare i log li' non serve?



Mmm, posso provare a ragionarci su?
Vediamo:
- se e' una pagina web, qualcuno (un web server) la deve generare, a meno che sia del tutto statica, ma non pare il caso, visto la presenza della cartina e della velocita', che sono dati dinamici. Allora chi genera la pagina web dove sta? come reperisce le informazioni da visualizzare? come si deve comportare se non e' in grado di riceverne? e come si deve comportare in presenza di "buchi" saltuari nei dati? Ed il browser che deve mostrare la pagina web, e' ammissibile che possa non funzionare? ed in tal caso come ci se ne accorge? e che comportamento si puo' tenere in questi casi?
- se viceversa ipotizziamo che non e' una pagina web, ma qualcosa d'altro, puo' essere che qualcosa non funziona bene? come reperisce le informazioni da visualizzare? come si deve comportare se non e' in grado di riceverne? e come si deve comportare in presenza di "buchi" saltuari nei dati?

Sei in grado di eliminare tutte queste domande, in modo da eliminare la necessita' di log per capire cosa succede nelle situazioni impreviste?

Se c'e' la riga che serve...e' sufficiente (a patto di riuscire ad accederci ). La mia idea e' che quando accendo un nuovo sistema e' meglio avere qualche riga in piu' che in meno, che poi lo vai a raffinare fino a loggare solo cio' che serve a seguire esattamente l'errore.

.
perfettamente d'accordo.
Pero' quando hai tempo da buttare via sono uno spasso da leggere!


Prego...spiega.

Io conosco 2 modi per far circolare informazioni:
- chi e' interessato se le va a cercare e le richiede (metodologia "on demand")
- chi le ha le distribuisce (metodologia orientata agli eventi)
E posso pensare di sceglierne una o l'altra in base alla situazione in cui mi trovo, ma....cosa ti fa dire che Dove6 riceve info da Oboe oppure che le richiede? ed in base a quale ipotesi hai effettuato questa scelta? siamo sicuri che sia l'Oboe a fornire dati al Dove6? se si, che tipo di connessione c'e' tra i due apparati? c'e' una rete cablata (LAN)? una rete wireless?
Dire "la scelta X e' concettualmente errata" mi pare possibile solo sapendo alcuni dati che non mi pare siano mai stati resi noti.

Ciao.

Non ne sono sicuro che mostri una pagina web. Avrebbe molta logica che facesse ciò, quindi ne deduco l'effettiva messa in opera così.


Il Dove6 dovrebbe querare ogni tanto l'Oboe e chiedere informazioni. La pagina web può anche non essere generata da nessun web server ma essere in locale e far uso di Javascript come si deve per aggiornarsi. In caso di Oboe irraggiungibile basterebbe che la cartina non si aggiornasse più. Se la condizione perdura, spegni il Dove6 che risparmi energia ed eviti di mostrare informazioni errate. Il Dove6 non è affatto uno strumento vitale, quindi o funziona o può stare tranquillamente spento. Si spera funzioni.



Può benissimo essere che qualcosa non funziona bene. E allora il log è inutile: se la situazione è un problema è riproducibile in officina/laboratorio, e si può investigare là. Se non è riproducibile si può banalmente riflashare la scheda con il software corretto (se fosse la flash difettosa) altrimenti si cambia l'hardware. Ci vuol meno tempo e il problema è sicuramente là. In caso di buchi nei dati vale la stessa considerazione di prima: il Dove6 non è uno strumento vitale, indi si spegne e si risparmia energia in caso di Oboe non disponibile.



Nel caso del Dove6 sì. In altri casi ho ben rimpianto l'assenza di log, non ti preoccupare, possiamo passare un pomeriggio al bar a parlare di log. Di come dovrebbero essere fatti, di come dovrebbero non essere fatti, di quando serve l'impostazione di verbosity invece di produrre sempre centinaia di mega di log, di quando una riga di log è inutile se non specifica informazioni, etc.

Senso forse hai frainteso la mia posizione: io non sono affatto contro i log. Sono contro i log inutili, o i log troppo densi di informazioni che non servono, che nascondono il vero problema in mezzo a righe banali.

Nei miei programmi da console destinati a roba embedded o server c'è l'opzione -v e dalla console si può aumentare in corsa la verbosity.


Semplicemente sto andando a intuito
Dunque vediamo.. una rete cablata direi che è quasi d'obbligo. Reti wlan ne ho viste solo per aggiornare i dispositivi SEPA delle carrozze Vivalto. Per quanto riguarda la scelta tra on-demand o event-driven ho pensato che la notifica degli eventi non ha molto senso logico per eventi continui, quanto invece per cose eccezionali o comunque impreviste (tipo segnalare la disponibilità di un aggiornamento software). Ripeto, non so dell'implementazione effettiva del Dove6 rispetto all'Oboe. Ma ho delle speranze e delle supposizioni. E vorrei capire perché questa ostilità verso di me.. non ho ancora mangiato nessuno, sto esprimendo pareri miei su come dovrebbe essere fatto il lavoro. Me ne assumo la responsabilità. Non ho criticato senza fornire alternative secondo me più pratiche.

Personalmente nessuna ostilita'.
Semplicemente curiosita' di informazioni nel capire giudizi, alcuni anche parecchio drastici, che io mi permetto solo quando conosco nei dettagio cio' di cui parlo, e che non mi permetto invece quando non posso che ragionare per ipotesi, ma io son fatto cosi', per questo mi diverto a indagare le origini delle valutazioni altrui

Dal mio punto di vista mi sembra un po' semplicistico dire che e' concettualmente errato qualcosa, se non si sa l'ambito reale in cui e' calato, e potrei obiettare diversi motivi per cui cio' che ti pare concettualmente errato potrebbe diventare del tutto sensato, come per esempio:
- in una rete con multicast
- in una rete con tanti client e server poco potente, tale per cui potrebbe non reggere il carico di tutte le richieste
- se il numero di eventi e' molto alto, il numero di sistemi connessi anche e la richiesta di uno "stato" richiederebbe una mole di dati da trasmettere non affrontabile
- se la rete non consente comunicazioni bidirezionali efficienti

Chissa' se qualcuno di questi casi e' applicabile al caso oboe/dove6 facendo diventare ragionevole cio' che ti pare concettualmente errato?
In ogni caso, nella mia esperienza ho trovato molto piu' comoda ed efficiente nella stragrandissima maggioranza dei casi la gestione ad eventi e quindi la comunicazione delle informazioni da parte di chi le ha, con messaggi del tipo "e' successo questo e quell'altro" e chi e' interessato ascolta e li riceve. Praticamente realtime, tempi di attesa ridotti all'osso, disaccoppiamento tra sistemi e possibilita' di connetterne uno nuovo senza dover fare sviluppo ad hoc. Tutto questo pero' su sistemi "a terra", e non in una situazione come quella del bordo treno.

Beh, OpenOffice è fatto in Java...

@Senso: piacevole trovare qualcuno con posizioni discordi ma che le difende con critiche ragionate. Io e te dovremmo prenderci un caffè assieme. Sì in effetti spesso son drastico e acido con i commenti, sarà che purtroppo per quelle brevi esperienze lavorative che ho avuto ho sempre trovato programmatori imbecilli tra i piedi. Del resto mi baso su supposizioni di come funzioni il Dove6 perché TSF non pare distribuire volantini su "come funziona il Dove6", forse qualche motivo ce l'hanno

@IODA: OpenOffice non è affatto un esempio che difende Java

Mi sa che TSF a momenti non sa nemmeno di averlo fatto..il Dove6
Per il caffe'...quando vuoi, non ho di certo problemi!

Si può darsi, ma ha il non trascurabile vantaggio di essere gratis

Stella stellina...



Cercando su google "oboe dove6 communication" guardate cosa esce...

http://www.stellastellina.org/html/powe ... ation.html

[OT]Io Java lo odio a priori, perchè mi diminuisce alcuni pagamenti di 2/3 [/OT]

Oh che bello! Finalmente una discussione nel mio campo! Anche io, infatti, mi occupo di sistemi embedded, e leggerò con piacere future evoluzioni della discussione. Appena avrò tempo dirò la mia sulle questioni sollevate (anticipo solo dicendo che il vecchio e bistrattato C è ancora il mio pane quotidiano).

Voglio solo dire qualcosa sulla questione dell'upgrade del firmware, che secondo me è stata liquidata semplicisticamente. Ma magari è ignoranza mia, e quindi esprimo la mia curiosità verso maggiori dettagli. In particolare, come ci si premunisce da errori in fase di scrittura? Ci dovrà pur essere un settore di backup in flash per garantire che l'operazione vada a buon fine. E allora la logica si complica...

Dove sbaglio?

Che probabilmente tu hai programmato troppo microcontrollori... E sei abituato a spazio stretto.

Vedila così: hai un loader fisso sul micro, e DUE aree di memoria a tua disposizione per il firmware.

All'avvio il tuo loader verifica la versione più recente disponibile, ne verifica il checksum, se il controllo fallisce va ad avviare la più vecchia.

Stessa cosa puoi fare con dei computer interi, embedded. Nella flash c'è un loader fisso, che guarda gli archivi (zip o tgz) disponibili ad esempio in root. Identifica quello più nuovo, vede se il checksum corrisponde a quello che era stato scritto in un terzo file con solo il checksum, in caso lo avvia, altrimenti significa che era fallito un caricamento di nuovo software e passa a quello più vecchio, dando anche pure per scontato che sia valido (tanto a questo punto cos'altro potrebbe succedere?)

La procedura di update, in dettaglio, farà così: identifica, dei due spazi a disposizione, quello col software più vecchio. Mossa prima: invalidare il checksum, per segnalare che lo spazio è libero. Così se si interrompesse a questo punto l'update non ci sarebbero problemi, il software corrente (aggiornato) è buono e verrà avviato come se ci fosse solo lui in flash. Poi scrive il checksum valido per il nuovo futuro file. Se si interrompe ora la procedura, stesso discorso di sopra. Poi inizia a scrivere il nuovo file. Se la procedura si interrompesse ora il checksum non sarebbe più valido, e si torna al software che funziona. Alla fine della scrittura del nuovo file si fa un reboot della macchina. Più facile di così

Se invece non è possibile fare reboot della macchina perché troppo vitale bisogna ricorrere ad aiuti del sistema operativo per sostituire al volo pezzi di codice... Con windows è possibile sostituire in memoria DLL al volo senza chiudere i programmi, con linux non so, dovrei informarmi. Ma non è facile in nessuno dei due casi.

In realtà la descrizione che hai dato mi torna perfettamente. Dalla precedente spiegazione sembrava che ci fosse un update diretto, invece.

Ok, quindi, nessun orizzonte nuovo: si ha il solito bootloader essenziale che decide quale kernel avviare....

In realtà c'è un'altra possibilità (e ci sto lavorando) che è quella di avere un aggiornamento basato sul delta tra un binario e il successivo con notevole risparmio di spazio (e questo nonostante sia necessario prevedere in flash lo spazio per l'agent dell'update e per opportune aree di backup che permettano di continuare l'update da dove si è interrotto).

Per tornare più o meno in topic, quali opportunità ci sono in Trenitalia (o RFI) per un ingegnere con esperienza nel campo dei sistemi embedded?

Bella domanda... Non lo so, non lavoro per Trenitalia (RFI) né tantomeno per la TSF (gruppo FS) che sarebbe l'artefice di vari dispositivi che Trenitalia usa sui treni. Per quanto ne so io, tutto il gruppo FS fa uso di dispositivi mission critical sviluppati direttamente da aziende consolidate nel campo ferroviario, mentre per le cose poco vitali (tipo le informazioni al pubblico, secondo il loro punto di vista) usano sistemi parecchio misti e in alcuni casi parecchio azzardati (tipo il sistema di controllo dei pannelli di stazione tramite ActiveX con Visual Basic, che secondo me è un accrocchio che sta in piedi con lo scotch, avendo lavorato con VB e ActiveX un bel po'). Alcuni sistemi sono fatti da SYSCO, altri da TSF stessa.

Dovresti chiedere a TeleServizi Ferroviari.