Newsgroup: it.lavoro.informatica
Titolo: dove sono gli sviluppatori bravi per il mobile ? Considerazioni

Mi ha contattato un amico. Ha una idea per una app da per i cellulari. 

Ne parliamo un poco. Ha già chiaro il modello di business, ha già chiari 

quelli che saranno gli step, ha pure un budget, non enorme ma 

importante, per lo sviluppo e il lancio.



Di programmazione non sa nulla e mi chiede di aiutarlo ma anche se la 

app è abbastanza semplice, per me non è possibile, non conosco gli 

strumenti di programmazione mobile e non avrei il tempo e gli suggerisco 

di cercare nel mondo dei freelance.



Per aiutarlo nella ricerca di uno sviluppatore parlo con un conoscente 

che conosce molto bene l'ambiente delle startup italiane per cercare dei 

contatti con sviluppatori e per risposta mi fornisce il suo quadro della 

situazione:

a suo dire è molto difficile trovare in Italia sviluppatori mobile 

esperti disponibili come freelance e i pochi ancora non con contratto 

fulltime con le grandi aziende non hanno la possibilità di accettare 

nuovi lavori. Addirittura mi dice che in questo periodo - se si ha 

esperienza - è meglio licenziarsi e fare il freelance perché il ritorno 

economico può essere veramente interessante.

Mi racconta di come questa scarsità sia a livello mondiale e che di 

conseguenza ci sono società estere pronte a reclutare le migliori teste 

(formate o comunque promettenti) anche in Italia con destinazione le 

"nuove Silicon Valley" che stanno sorgendo negli USA e mi porta un 

esempio reale.



Oggi, sul fatto, c'è l'ennesimo articolo su un cervello italiano in 

fuga, un informatico sviluppatore mobile, la cui storia parzialmente 

coincide con quella raccontatami dal mio amico.



Vorrei quindi, senza trasformare il thread in rissa e insulti, cercare 

di capire con voi se la situazione così come descritta dal mio amico 

rispecchia quella attuale dello sviluppo mobile in Italia.



E dello sviluppo software non mobile?




 Vorrei quindi, senza trasformare il thread in rissa e insulti,



No allora non se ne fa niente ... :-)










 importante, per lo sviluppo e il lancio.

CUT



amico, è il solito sempre trito discorso..... in soldoni: se il

tuo amico ha *veramente* un budget da investire in questo progetto,

beh basta che caccia li sordi e troverà sicuramente chi lavorerà

per realizzarlo... ;)




 per realizzarlo... ;)



hai voglia. se tira fuori la mammella sai quanti poppanti arrivano...




 per realizzarlo... ;)



Il budget c'è, anche per la parte programmazione... non sta cercando un 

partner che si assuma il rischio ma uno sviluppatore puro, che faccia il 

lavoro su commessa. E l'importo che ha stanziato non è piccolo.





Abbastanza fedele, anche perchè il time to market per le app mobile è relativamente basso,

quindi ieri lo sviluppatore doveva sobbarcarsi una serie di attività molto ampia (e che tipicamente

lo schifavano abbastanza: vendite, marketing, distribuzione etc) mentre oggi puo' entrare in un

mercato gigantesco velocemente.

In Italia ci sono i Fungo (
http://www.fungostudios.com/
), nonostante siano in Farm sono molto

molto bravi, se vuoi un contatto piu' diretto te lo passo, sono amici.



  ngw






forse mi sono spiegato male. La ricerca dello sviluppatore non l'ha 

ancora iniziata. Abbiamo chiesto a questo conoscente per avere delle 

indicazioni e quando ho letto l'articolo mi è tornata in mente la sua 

risposta e ho chiesto un vostro parere.



Del fatto che arrivino i poppanti ne sono certo. Che siano preparati e 

capaci di portare a termine il lavoro è la cosa che a lui più interessa.


 E dello sviluppo software non mobile?



Guarda, per le cose "da polli di batteria" immagino che la situazione 

sia quella che conosciamo.

Pero' se si una una specializzazione particolare (leggi: se si e' 

particolarmente bravi in qualcosa) le opportunita' anche in italia e con 

la situazione che abbiamo non mancano affatto. Poi tutto sta a decidere 

se si vuole rimanere in questo paesaccio, ma questo e' un altro discorso.


 forse mi sono spiegato male. 



anch'io mi sono spiegato male. rispondevo a ciccio, il quale mi pare

lasci intendere che basti pasturare per prendere il matsugoro. in realtà

la mia esperienza è che a giro ci sono tanti pesci gatto buoni solo a

magnarsi la pastura.



per tornare in tema: un errore di valutazione che vedo spesso fare a chi

"ha l'idea" per una app mobile è cosiderare solo lo sviluppo sul 

dispositivo. ne parlavo giusto pochi giorni fa. non so ovviamente in cosa

consista quel progetto, ma il punto di forza della quasi totalità delle

app in circolazione è di sfruttare sempre e comunque la connettività 

tipicamente con una parte server che è il core dell'applicativo. ho fatto

caso che difficilmente un non-tecnico ha chiaro che per realizzare la sua 

idea lo sviluppo sul dispositivo è solo una parte dello sviluppo e neanche

la più impegnativa.






 economico può essere veramente interessante.



Immagino, come sempre, che ci sia da capire bene cosa si intende per sviluppatore mobile "bravo". Il mercato del mobile è di sviluppo piuttosto recente e non penso faccia grandissimi numeri in Italia, quindi effettivamente posso credere che non ci siano sul mercati tanti specialisti "veri" che conoscono a fondo il dominio e che si mantengono doverosamente aggiornati (che mi sa è la parte più difficile, vista la velocità con cui si muove il mercato e l'esigenza di time to market ristrettissimi). Magari già più facile se cerchi uno sviluppatore bravo e di esperienza che si sa un po' muovere anche sul mobile e che potrebbe buttarcisi sopra in caso si presenti una buona occasione. 



bye!




due ex colleghi che lavorano su Android hanno tagliato la corda e ora si trovano a Londra un altro specialista su Iphone/Ipad adesso è in Germania.Credo che anche in questo settore se vuoi fare buoni margini l'unica via sia  l'espatrio.


 Immagino, come sempre, che ci sia da capire bene cosa si intende per sviluppatore mobile "bravo". Il mercato del mobile è di sviluppo piuttosto recente e non penso faccia grandissimi numeri in Italia, quindi effettivamente posso credere che non ci siano sul mercati tanti specialisti "veri" che conoscono a fondo il dominio e che si mantengono doverosamente aggiornati (che mi sa è la parte più difficile, vista la velocità con cui si muove il mercato e l'esigenza di time to market ristrettissimi). 





Però, se è vero, vuol dire che è un mercato, per quanto attualmente asfittico, piuttosto vergine, e dunque appetibile. Il problema, come sempre, è 1) come entrarci e 2) individuare le risorse commerciali necessarie.



-- 

Ciao!

Luca


 tipicamente con una parte server che è il core dell'applicativo. 



E' esattamente ciò che dicevo a un amico che stava sviluppando l'idea per un'app che avesse a che fare con lo sci: "hai la sicurezza che chi ti fa lo sviluppo abbia le competenze anche lato server?"



-- 

Ciao!

Luca


 due ex colleghi che lavorano su Android hanno tagliato la corda e ora si trovano a Londra un altro specialista su Iphone/Ipad adesso è in Germania.Credo che anche in questo settore se vuoi fare buoni margini l'unica via sia  l'espatrio.



ma guardà un pò fresco fresco:



http://www.ilfattoquotidiano.it/2014/02/04/informatico-a-londra-assunto-al-telegraph-dopo-una-app-sullolio-doliva/864898/




Qui, infatti, prima del successo londinese nessuno lo aveva mai cercato. L'unico contatto è quello con una storica casa di moda italiana, che, durante l'esperienza presso la società di ecommerce gli offre "un contratto a tempo indeterminato a un terzo dello stipendio, per lo stesso tipo di lavoro". Che lui rifiuta. Nel Regno Unito Emilio scopre un mercato del lavoro molto diverso: "In Italia ho lavorato 5 anni senza riconoscimenti e senza poter crescere professionalmente, anche perché erano tutti 'baroni'. A Roma i manager arrivavano anche a 88 anni, a Londra ne hanno 35. E poi è l'organizzazione del lavoro ad essere diversa: nelle aziende non ci sono pagamenti in nero, straordinari non pagati. Il riposo è considerato fondamentale in un'ottica di rendimento. E al Telegraph, per esempio, se porti qualcuno di talento in un settore dove loro hanno bisogno, ti danno mille pound di premio, perché li hai aiutati a migliorarsi".


 la più impegnativa.



Questo è molto interessante. E potenzialmente amplia le opportunità di lavoro anche a chi non ha conoscenze particolarmente approfondite sui dispositivi (non significa che può ignorare del tutto il lato dispositivo, sia chiaro).






 E dello sviluppo software non mobile?



Non saprei darti un feedback verosimile, pero' potresti dare un'occhiata i questi 2 gruppi:



 
https://www.facebook.com/groups/startup.webdesigners.developers/




   STARTUP cercano componenti TEAM:

 
https://www.facebook.com/groups/510459342359022/


 
http://www.linkedin.com/groups/STARTUP-cercano-componenti-TEAM-5085025?gid=5085025&trk=hb_side_g





 



appunto... E aggiungo come integrazione al post di risposta precedente:

Negli anni scorsi dove il commercio elettronico era pure sulla bocca

del macellaio sotto casa, dei contatti mi chiesero se si poteva

imbastire un sito di commercio elettronico. (Nel loro cervello infatti

ogni giorno un'unica frase si ripeteva: "COMMERCIO ELETTRONICO!

COMMERCIO ELETTRONICO! COMMERCIO ELETTRONICO! COMMERCIO ELETTRONICO!

COMMERCIO ELETTRONICO! COMMERCIO ELETTRONICO! COMMERCIO ELETTRONICO!

COMMERCIO ELETTRONICO! COMMERCIO ELETTRONICO! COMMERCIO ELETTRONICO!").

Preparato il demo e visionato, sembrava sempre tutto bene, tranne quando si

passava al preventivo, allora la frase suddetta spariva istantaneamente

e non si faceva più niente.



Ora la frase che si ripete nel loro cervello è: "APP MOBILE! APP MOBILE!

APP MOBILE! APP MOBILE! APP MOBILE! APP MOBILE! APP MOBILE! APP MOBILE! 

APP MOBILE! APP MOBILE!"



E la storia si ripete.

c.v.d.




 ha scritto:


E allora che faccia un annuncio con selezione attenta e oculata

di un professionista adatto per l'incarico, non vedo dove sia il

problema.




 rispecchia quella attuale dello sviluppo mobile in Italia.



Confermo un amico ha trasferito l'azienda all'estero perchè non trovava 

profili professionali abbastanza competenti, l'alternativa era 

trasferirsi a Milano o a Roma. C'è effettivamente carenza di 

sviluppatori mobile in quanto i pochi che ci sono non hanno tempo di 

seguire altri progetti. Chi ha competenze su objective-c è ancora più 

difficile da reperire.

Attualmente io sto sviluppando su piattaforme mobile tramite sistemi 

ibridi nativi/html5 (con un sacco di problemi), anche se effettivamente 

qualche vantaggio c'è. Dipende tutto sempre dal tipo di progetto che si

sta sviluppando.



ps

Comunque sia consiglia al tuo "amico", se veramente tuo amico di 

pensarci bene,  Riuscire a cavare fuori soldi da un'app non è una 

passeggiata e i rischi di fare flop sono MOLTO elevati con conseguente 

perdita di tempo e denaro.

Senza contare che non sapendo nulla come fa determinare la competenza di 

una risorsa? Se gli posiziona bene un pulsante? boh.



ciao





-- 

http://www.evilripper.net


http://www.flickr.com/photos/evilripper/



 perdita di tempo e denaro.



L'app, nelle intenzioni, non è a pagamento, forse potrebbe avere in 

futuro deagli acquisti in-app... ma non è nemmeno detto..



Sinceramente non ho ancora capito bene il perché lo voglia fare... ma 

c'è chi si compra un'auto di lusso, chi borse da 1000 euro, chi una 

vacanza ai tropici... lui vuole veder realizzata questa sua idea...


 vacanza ai tropici... lui vuole veder realizzata questa sua idea...



Si chiama forse Silvio? O forse Flavio? No, magari Luca... :-))


 lasci intendere che basti pasturare per prendere il matsugoro. 



in quale puntata di sampei era ? :)



-- 

Soprano







----Android NewsGroup Reader----

http://www.piaohong.tk/newsgroup



 



Il solito Emilio che ha fatto esperienze in Italia poi in UK e da

 quelle ne generalizza verita' assolute per tutti i lavori in

 Italia e UK. 



 Si chiama forse Silvio? O forse Flavio? No, magari Luca... :-))



Si chiama Gianluca.


 perdita di tempo e denaro.



Curiosità: mi espandi questo ragionamento?

Qualche mese fa ho visto un sistema di gestione magazzino in cui le pistole per i bar code sono state integralmente sostituite da smartphone e da un'apposita app. In questo caso, l'app non vive a se ma fa parte di un sistema più complesso.

Ho detto 'bello', però non ho esperienza nel campo per sapere se un approccio in cui un'app non è altro che una commodity di un sistema sia interessante e/o economicamente vincente. Tu che ne pensi?



-- 

Ciao!

Luca


 Ho detto 'bello', però non ho esperienza nel campo per sapere se un approccio in cui un'app non è altro che una commodity di un sistema sia interessante e/o economicamente vincente. Tu che ne pensi?



Huh? A me me pare 'na stronzata. Usare uno smartphone in un magazzino al posto delle pistole è come dare a un muratore un paio di guanti di cotone bianco... e non vedo dove sia il vantaggio dato che le "pistole", dal punto di vista HW e SW, sono praticamente equivalenti a degli smartphone (ovviamente a parte il fatto che non hanno la sezione "phone", nè le altre fighetterie). 

Avrebbe senso solo se fosse un magazzino aperto al pubblico, dove ognuno può usare il proprio device, ma non conosco simili realtà...



Bye!




e/o economicamente vincente. Tu che ne pensi?



Vantaggi della pistola:



- Ergonomica

- Standard

- Alta autonomia

- Rapida

- Economica



Vantaggi dello smartphone:

- Angry birds ?

-- 

Living in Barbaropoli

http://www.barbaropoli.com



On 05/02/14 15.10, Hermooz ha scritto:


Ad es. per il gestionale WooCommerce (che gira su WordPress), che sto 

usando per un e-commerce di prossimo avvio, c'è una App che crea/stampa 

dei QR collegati ai prodotti che inserisci e lo trovo molto interessante.

Un magazzino non è per forza qualcosa di sporco con gente che usa il 

muletto ;)



Riguardo la tua ultima osservazione, ci sono dei negozi tipo Toys R US 

dove puoi scansionare i codici per sapere il prezzo usando dei loro 

scanner, ora immagina che potresti dare una App per fare la stessa cosa 

dall smartphone dei clienti direttamente sulle scatole.

Sull'iPhone io uso un paio di App che ti dicono ad es. se quel prodotto 

costa meno altrove di dove lo hai comprato, usando sia il codice a barre 

che eventualmente il QR e lo confrontano con gli e-commerce che indicano 

questi dati pubblicamente.



ciao

Gabriele






On 05/02/14 15.32, Freddy Krueger ha scritto:


- la commessa lo sa già usare

- sempre in tasca

- rapido comunque

- app già esistenti



:)



Gabriele






 Qualche mese fa ho visto un sistema di gestione magazzino in cui le pistole per i bar code sono state integralmente sostituite da smartphone e da un'apposita app.



scusa quale sarebbe il senso?

come minimo uno smartphone non ha lettore barcode, fare uso intensivo della 

fotocamera di uno smartphone come lettore è semplicemente stupido. ma giusto

per fermarsi al primo difetto.




- app già esistenti

Per leggere un codice a barre sicuramente, per interfacciarti col tuo

backend parliamone.



 costa meno altrove di dove lo hai comprato



mi dici il loro nome ?


 mi dici il loro nome ?



Una si chiama Quick Scan (Pro), però IMHO è meglio Quick Mark.



ciao

Gabriele




 condizioni di luce



su questo avrei forti dubbi. Il barcode e' una serie di linee nere della stessa lunghezza, con larghezza variabile e su sfondo bianco. Hai una ridondanza di dati eccezionale: il problema e' in una dimensione (1D), ma hai l'input in 2 dimensioni (2D)!!!! in piu' aggiungici che hai anche una ridondanza dei canali di colore, e per ogni canale il classificatore e' binario, visto che i valori di bianco e nero sono uguali per ogni canale. Per fare un'applicazione che sbagli i barcode ci vuole veramente tanto impegno :-)






 scusa quale sarebbe il senso?



Siete troppo "tecnici".

A parte che le pistole wireless fanno cacare in un magazzino gia' di 

medie dimensioni, vuoi mettere come il commerciale riesce a vendere un 

sistema che comprende degli ipod (o quello che si vuole usare, un 

android cinese costa quasi come un lettore di barcode ormai) piuttosto 

che una cosa con le pistole per i barcode?

Che poi col suo smartphone puo' vedere le statistiche e i cazzi e i 

mazzi e magari anche da casa e tante altre menate, troppo piu' fico.





Non scendo nei dettagli, ma non e' cosi' semplice.


 Ho detto 'bello', però non ho esperienza nel campo per sapere se un approccio in cui un'app non è altro che una commodity di un sistema sia interessante e/o economicamente vincente. Tu che ne pensi?



Non entrando nel caso specifico se sia un bene o male usare uno 

smartphone come lettore di barcode, secondo me il futuro delle app sarà 

proprio questo, essere parte di sistemi più complessi per rendere tali 

sistemi più competitivi e più appetibili. Che vi piaccia o no prima o 

poi saremo tutti costretti ad usare un app  per fare sempre più cose 

(domotica,automotive etc.. ringraziate pure Jobs e Google), con che 

device? boh :-)








 



ho preso il libro di questo tizio per valutare la tecnologia di programmazione su Android,



http://www.massimocarli.eu/




uno dei massimi esperti italiani di programmazione su dispositivi Android.

sul blog leggo che abitava a rovigo ma in seguito si è trasferito con tutta la famiglia a Londra.



Che dici un altro Emilio?






 su questo avrei forti dubbi. Il barcode e' una serie di linee nere della stessa lunghezza, con larghezza variabile e su sfondo bianco. Hai una ridondanza di dati eccezionale: il problema e' in una dimensione (1D), ma hai l'input in 2 dimensioni (2D)!!!! in piu' aggiungici che hai anche una ridondanza dei canali di colore, e per ogni canale il classificatore e' binario, visto che i valori di bianco e nero sono uguali per ogni canale. Per fare un'applicazione che sbagli i barcode ci vuole veramente tanto impegno :-)



Credo che la pistola, col suo laserino, abbia comunque molti meno vincoli e problemi. Magari può funzionare pure al buio, estremizzando. 

Piuttosto un giorno ho visto l'omino della lettura del gas che usava un apparecchio, il quale faceva per l'appunto la semplice fotografia del normalissomo contatore, con successivo OCR, ed poi memorizzazione e trasmissione del numero letto. Forte! :-)


 


Cioè  l'operaio del magazzino a casa sullo smartphone si guarda le statistiche del magazzino? Invece di fare i giochetti tutti colorati??? :-))))


sbagli i barcode ci vuole veramente tanto impegno :-)





Ripeto: la camera dello smartphone il codice a barre lo deve prima ***

METTERE-A-FUOCO ***



Ci possono volere fino a 3 secondi per acquisire un codice a seconda

del telefono, della velocita' della messa a fuoco, della luce.



Con un lettore tradizionale la lettura puo avvenire anche col codice

in movimento, visto che il sensore campiona continuamente.





In ordine di importanza:

1- il selezionatore sappia riconoscere/misurare le capacità del 

professionista;

2- chi deve pagare possa pagare la parcella del professionista



Detto niente...

IMHO.






 in movimento, visto che il sensore campiona continuamente.



guarda che col lettore tradizionale hai molta meno ridondanza di dati in ingresso. Programmato per bene, e' molto piu' accurato il telefonino del lettore laser. Salvo insomma, dover fare la scansione al buio, in tal caso si puo' anche usare il flash.



Ripeto, quello dei codici a barre e' un problema estremamente semplice, perche' hai in ingresso molti piu' dati di quelli che in realta' ti servono.


Il 05/02/2014 15:58, Freddy Krueger ha scritto:> On Wed, 05 Feb 2014 


io mi sono interfacciato 4 anni fa con il mio gestionale. l'app android 

barcode permette di aprire un url a caso con il barcode scansionato come 

variabile GET...




 Non metto in dubbio, ma "magazzino" non è per forza quello di Amazon :)



anche questo è pacifico ma il problema non è di dimensioni del magazzino.



un dispositivo che legge a non più di 5 cm di distanza non è adatto a 

quel mestiere, punto. un conto è offrire servizi per esempio ai clienti 

grazie agli smartphone già in loro possesso, un conto invece è adottare 

questi dispositivi al posto di quelli industriali. 



All'operatore che deve fare la scansione di 100 prodotti su un bancale

gliene fotte una sega dell'entropia, della ridondanza dei dati, degli

algoritmi e del chitemmurto.



Con la pistola acquisisce un codice ogni volta che schiaccia sul

grilletto (diciamo facciamo che acquisisce 2 prodotti al secondo) e

anche se passa davanti al codice a barre in movimento.



Col un telefono deve aspettare FINO A TRE SECONDI!!!

Cioe' potenzialmente ci mette fino a sei volte di piu' ad acquisire lo

stesso numero di codici.



Cosa c'e' di difficile da capire?!?



variabile GET...



Quindi passiamo da mezzo secondo a >10 secondi per acquisire un codice

e confermarlo? :)



 Una si chiama Quick Scan (Pro), però IMHO è meglio Quick Mark.



La prima fa comparazione di prezzi (ma funziona in Italia? prendi un 

codice da un detersivo e mi dici cosa trova?) mentre la seconda non mi 

sembra...


 Living in Barbaropoli



ti sei adeguato ben bene vedo :-) :-)



afaik non sono informazioni facilmente reperibili/collezionabili, l'unico 

modo è coinvolgere l'utenza ad un ruolo proattivo. le catene della gdo 

spendono fior di soldoni per la rilevazione concorrenza...


 Huh? A me me pare 'na stronzata. 



Mica tanto. 

Primo, la pistola fa solo la pistola, a meno che non prendi quelle trappole embedded con il loro bravo SO a bordo - solo che a quel punto ti costano molto più di uno smartphone di fascia media.

Secondo, per ovvi motivi io sono stato sintetico, ma non è che quell'app, integrata alla gestione magazzino, si limitasse alla scansione dei bar code...



-- 

Ciao!

Luca


 - Economica



Se vuoi una pistola che fa solo la pistola, magari attaccata a una porta USB, ok.

Se vuoi una pistola magari wireles, in cui vuoi poter mettere dentro un po' di logica, mica tanto... Io ricordo che la pistola su cui ho messo le mani io non era proprio economicissima: ricordo vagamente cifre intorno ai 300/400 euro, calamaio compreso, pero' potrei dire una sciocchezza; certo, non erano le poche decine di euro di un lettore USB.



-- 

Ciao!

Luca


 Non scendo nei dettagli, ma non e' cosi' semplice.



"Se mi piacessero le cose semplici, non svilupperei software" (cit. Luca Menegotto, 1999)



;-)



-- 

Ciao!

Luca


 Col un telefono deve aspettare FINO A TRE SECONDI!!!



Io sinceramente non ricordo tempi del genere...



-- 

Ciao!

Luca


 potenzialmente ci puo' mettere anche 100 volte di piu' se ci metti una capra a scrivere il software e lo carichi su un cellulare inadeguato. Cosi' come potresti metterci 100 volte di piu' se usi un lettore laser programmato dalla capra di cui sopra. Potenzialmente, con le immagini hai piu' ridondanza, quindi c'e' meno possibilita' di sbagliare il codice.



Ma se ci sono questi vantaggi così forti e numerosi (concordo anche sulla non necessità di perfetta messa a fuoco), come mai le pistole ed anche gli scanner da banco insistono ad usare circuiti laser, piuttosto che una telecamerina da 4 soldi con un computerino dedicato, tipo raspberry a dir tanto?




 (e t'ho spiegato perche')



no in realtà questa la devi spiegare meglio. il fuoco è un principio 

ottico che sta a monte dell'acquisizione dell'immagine e quindi anche 

della sua interpretazione: se la luce non converge correttamente il 

sensore non cattura l'immagine del barcode, ovvero se i pixel a margine 

delle aree bianche e nere sono confusi mi pare ovvio ti manchi 

l'informazione. no?


 di cercare nel mondo dei freelance.



Se hai bisogno di qualcuno bravo per iOS scrivimi che ti metto in contatto con un amico.




 l'informazione. no?



spiegato sopra :-)




 l'informazione. no?



Penso che si riferiva al fatto che in molti casi bisogna comunque filtrare e modificare l'immagine, prima di analizzarla. Il concetto di "fuoco" è relativo alla visione umana, non necessariamente all'elaborazione delle immagini per scopi diversi.

Ad esempio: a volte si applicano all'immagine due successive operazioni, una di "erode" ed una di "dilate", ciò al fine di eliminare le piccole imperfezioni a livello di pixel o poco più. A quel punto però l'immagine finale all'occhio umano risulta più sfocata rispetto all'originale.




 finale all'occhio umano risulta più sfocata rispetto all'originale.



non è che appare solo all'occhio umano, anche un software che 

successivamente rilegge il bitmap ritrova i pixel diffusi. se con questo 

processo hai "eliminato le piccole imperfezioni" vuol dire che questi 

particolari li hai persi non solo all'occhio ma anche ad un eventuale 

software che scansiona il bitmap.




 Piu' chiaro ora?



più chiaro sicuramente no :-))))



però sicuramente c'è una logica dietro ....



quindi i programmi che ho usato e che fanno le scansioni di barcode su 

android fanno una cavolata perché perdono tanto tempo a mettere a fuoco 

(e spesso non ci riescono) e poi all'interno del codice sfocano per 

utilizzare un algoritmo... magari ne usano un altro ?

E non so nemmeno se sia possibile disabilitare la messa a fuoco...


 > all'elaborazione delle immagini per scopi diversi.



Ok, sai tutto tu.




 si limitasse alla scansione dei bar code...



questo e' gia' piu' comprensibile; tuttavia sarebbe valutare 

l'effettivo vantaggio di spostare l'intelligenza sull'end device invece 

di avere la consueta piattaforma centralizzata di elaborazione



l'unico motivo che mi viene in mente e' che si tratti di un magazzino 

senza copertura radio o wifi, e che si voglia fare di necessita' virtu' 

pre-elaborando i dati sullo smartphone offline per poi riversarli tutti 

insieme una volta ottenuta la connessione





-- 

So I throw the windows wide

And call to you across the sky


 elecamerina da 4 soldi con un computerino dedicato, tipo raspberry a dir tanto?



ogni metodo ha i suoi pro e i suoi contro ;-)

Gli scanner laser sono sul mercato da decenni, e' una tecnica matura e testata.

Quello che dico e' che le analisi delle immagini non sono da meno, e non ci vedo grossi problemi tecnici per usarle dal telefonino. Tutto qui.




 uno smartphone



Lo smartphone perà fa anche da livella di precisione :P





G.




 E non so nemmeno se sia possibile disabilitare la messa a fuoco...



dipende dal cellulare immagino. Il problema piu' grosso credo che sia avere l'immagine ferma, piu' che a fuoco. Ma comunque, sapendo che le linee son rette, che il barcode e' rettangolare, una deconvoluzione risolve anche gli artefatti da movimento. E sapendo che i colori sono solo bianco e nero, e' ancora piu' facile definire il region of interest basato sul color pattern. 



Insomma, non e' un problemone :-)




 di avere la consueta piattaforma centralizzata di elaborazione



Mai detto questo. Intendevo dire che l'App, oltre a far da lettore, consentiva un colloquio piuttosto efficiente con l'applicazione centrale. Esempiello: dato un codice di magazzino, voglio conoscere le giacenze correnti, gli ordini che lo coinvolgono, ecc. ecc. ecc.

Capisci che avendo una periferica programmabile, il limite quasi è la tua fantasia. E, aggiungo, per esperienza un lettore di bar code programmabile non è così economico.



-- 

Ciao!

Luca



ok, mi sono segnato il tuo riferimento e lo passerò se deciderà di 

procedere.


 Capisci che avendo una periferica programmabile, il limite quasi è la tua fantasia. E, aggiungo, per esperienza un lettore di bar code programmabile non è così economico.



Tutto sta a capire se il lettore costa di più del telefonino per ragioni ben precise, o per semplice avidità del venditore... :-)

Senza contare che la forbice dei prezzi dei telefoni è enorme. La app di cui parli viene usata su telefonini da grande magazzino?






 Senza contare che la forbice dei prezzi dei telefoni è enorme. La app di cui parli viene usata su telefonini da grande magazzino?



Francamente non me lo ricordo, ma sicuramente non erano degli iPhone (mi pere fossero LG, ma potrei dir minchiate).



PS. Ormai gli SP di fascia media sono molto abbordabili.



-- 

Ciao!

Luca


 per esperienza un lettore di bar code programmabile non è così economico.



ah, ho capito adesso



allora si', concordo che da questo punto di vista non ho esperienza di 

pistole scanner che abbiano anche le sopra citate funzionalita'



 Insomma, non e' un problemone :-)



Ripeto, non e' cosi' semplice. Certo dipende dal tipo di garanzie che 

vuoi ottenere. In ambito industriale puo' non essere accettabile un 

sistema che sbagli anche una lettura su mille, col cellulare magari se 

ogni tanto ti bippa e ti dice di rifare la lettura non e' un problema.






 ogni tanto ti bippa e ti dice di rifare la lettura non e' un problema.



Dipende da come e' programmato e da quali sono i requirements.



Qui stiamo parlando a mo' di chiacchera, e sempre a mo' di chiacchera m'e' capitato piu' d'una volta al supermercato che la macchinetta laser cannasse il codice. Il fatto e' che non esiste una tecnologia che ti consenta un margine di errore zero. Ovvio anche che se fai un'applicazione su HW dedicato le possibilita' di errore sono minori, e applicazioni su architetture general purpose hanno piu' probabilita' d'errore.






 Ok, sai tutto tu.



che vuoi che ti dica, che hai ragione a dire che il fuoco in ottica è solo

una sensazione visiva?

mah.




 Non tutti i cellulari hanno la messa a fuoco automatica, e/o si potrebbe anche disabilitarla.



E' dell'adeguatezza della soluzione che si sta discutendo.



Un lettore dedicato legge a distanze che vanno dai 10cm ai 200metri a

seconda della larghezza delle barre (e.g. ho visto specifiche per

lettori che leggono a 26 metri codici con barre larghe 2.54cm)



Chiaro che volendo puoi anche usare un commodore 64 e un

digitalizzatore video...



Tralasciamo poi il discorso autonomia.



-- 

Living in Barbaropoli

http://www.barbaropoli.com



Io sinceramente non ricordo tempi del genere...



Dipende se sei costretto o meno a mettere a fuoco il codice, da quanto

e' veloce la messa a fuoco, dalla luce ambientale (meno luce c'e',

piu' devi aspettare quando la messa a fuoco non e' disattivabile), dal

materiale su cui e' stampato il codice.



Relativamente al materiale, se il telefono usa un led per illuminare

l'etichetta e il materiale e' rilettente, ti potrebbe capitare di

accecare il sensore.



Poi in condizioni ottimali ci metti meno.



Se vuoi una pistola magari wireles, in cui vuoi poter mettere dentro un po' di logica, mica tanto... Io ricordo che la pistola su cui ho messo le mani io non era proprio economicissima: ricordo vagamente cifre intorno ai 300/400 euro, calamaio compreso, pero' potrei dire una sciocchezza; certo, non erano le poche decine di euro di un lettore USB.



Vero: ho visto pistole wireless anche da 700 e passa dollari.



E' che quando mi dici smartphone, io lo so che ci sono telefoni cinesi

da 50 euro, solo che mi immagino che poi vogliano tutti usare un

Samsung S4 o un iPhone che costano piu' dei 300/400 euro delle pistole

che hai visto tu... :)



 programmabile non è così economico.



La intermec produce palmari a partire da 400 euro. Ma a parte questo non 

mi capacito di questo modo di valutare i costi: far fare ad un qualsiasi 

smartphone il mestiere dello scanner vuol dire tenerlo fisso con la 

fotocamera accesa, ovvero tempo due ore è morto. A maggior ragione se 

nello scegliere il dispositivo ti sembrano troppi 400 euro...






 che hai visto tu... :)



Cinesi, samsung, iphone non reggono il confronto con una pistola barcode 

in quanto ad erogonomia !

Le pistole poi sono "rugged"... se l'iphone cade....




 visto tu... :)



già ho dei forti dubbi che uno smartphone di fascia alta possa reggere il 

confronto in questo genere di utilizzo, mettici anche la cinesaglia e 

siamo a posto... te lo immagini scannerizzare in magazzino con il lag di 

una fotocamera e/o processore di fascia bassa? te la immagini poi la 

produttività se dopo tre ore di utilizzo la batteria ti lascia a piedi?




 spiegato sopra :-)



premetto che non è il mio campo per cui non ho mai seriamente visto la 

teoria all'atto pratico, ma siamo certi che sia *realmente* applicabile 

alla lettura di un barcode/qrcode? io ho visto per esempio le telecamere 

di controllo traffico all'opera ma mi pare un'altra cosa. se tu fotografi 

un codice ad un metro e poi a mezzo metro senza cambiare fuoco la seconda 

immagine viene fuori una macchia grigia, chiunque ha fatto un po' di 

fotografia sa che la profondità di campo non c'è con le distanze brevi e 

poca luce (quindi diaframma aperto). a me sembra ci sia proprio un 

problema di ordine pratico in questa applicazione.




 un codice ad un metro e poi a mezzo metro senza cambiare fuoco la seconda 



e se devi fare la scansione di un bacode sott'acqua? E se l'operatore e' appeso a testa in giu' e con una mano mangia un panino e con l'altra deve fare la scansione di un barcode a 3 isolati di distanza? Non esageriamo, stiamo parlando di applicazioni normali e uso normale.



Pour parler, tra l'altro il mio ex cellulare l'ho portato a -10 sott'acqua, con una custodia pagata $1 da Hong Kong, e ci ho fatto anche delle belle riprese :-)








produttività se dopo tre ore di utilizzo la batteria ti lascia a piedi?



No, appunto.



E' quello di cui cercavo di discutere con askaholik.



Puoi usare uno smartphone come scanner di codici a barre? Si.

Lo fara' meglio di un hardware dedicato? No.



Comunque in condizioni di luce scarsa lo smartphone di fascia alta ha

tempi di reazione paragonabili alla cinesaglia.



 esageriamo, stiamo parlando di applicazioni normali e uso normale.



sinceramente non capisco cosa ci trovi di anormale in quello che ho 

scritto...


 scritto...



Qui da me al supermercato c'e' il check out self service, dove sono i clienti che passano i prodotti allo scanner (non so se c'e' anche in Europa), i codici a barre li legge a una distanza di max 10-20 cm. Sempre al supermercato, i commessi che aggiornano i prezzi dei prodotti con la pistola laser, la avvicinano al codice. Non li ho mai visti scansionare un prodotto a 20 metri di distanza, e francamente mi sembrebbe anche a stupida come cosa.



Il sensore delle telecamerine dei cellulari sono piuttosto scadenti, e hanno un valore di qualche decina di euro (bene che vada), ciononostante credo che riconoscere un codice a barre da un'immagine sia un problema semplice. Ovvio che mi riferivo ad una scansione da relativamente vicino, in modo da avere una risoluzione spaziale di circa 0.5mm/px. Se vuoi fare la scansione dei codice a barre da 1 metro e mezzo, devi avere un sensore adeguato, e delle lenti adeguate. Non ha senso confrontare il sensore del telefonino con HW dedicato. Dammi un CMOS da 800 euro, corredato da un'ottica adeguata e ti facco la scansione dei codici a barre a 20+ metri di distanza. Ma stiamo a discutere del sesso degli angeli. Io ho solo detto che il codice a barre e' un problema piuttosto semplice da risolvere con immagini, e ho cercato di spiegare perche'.


d'errore.



Ci sono dei casi (non il supermercato) in cui non puoi permetterti di 

"cannare il codice", a meno di probabilita' infime.

Fare un coso che legga i codici nel 99% dei casi e' facile, i cazzi arrivano 

quando vuoi leggere anche l'ultimo 1% e la

messa a fuoco, giusto per tornare all'argomento iniziale, e' fondamentale. 




 E' esattamente la stessa formulazione matematica. Piu' chiaro ora?

Temperatura e tempo sono grandezze continue, i pixel no. Allargare la 

gaussiana significa attribuire a piu' punti la stessa probabilita' di 

essere o colorati o meno, ovvero attribuire a tutti i punti una 

misurazione continua (l'intensità di grigio, che dici tu) basata sulla 

probabilità determinata dalla gaussiana. Quindi, se lo scopo 

dell'analisi statistica era di regredire al valore originale, si 

tratterà di analizzare la distribuzione della varianza dell'errore 

introdotto dalla messa a fuoco difettosa.

Alla fine dovrai decidere se ad una certa probabilità corrisponda un 

pixel colorato o no, proprio perchè i pixel sono colorati in modo 

discreto e non continuo.





---

Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus.

http://www.avast.com





 semplice da risolvere con immagini, e ho cercato di spiegare perche'.



ti piace vincere facile :-) che su immagini definite sia un problema 

relativamente semplice era intuibile anche senza scomodare la teoria, 

visto che esiste codice già scritto ottimo e abbondante. e in ogni caso 

la discussione era sull'opportunità di usare gli smarphone, non una 5d 

mkii + 70-200l f2.8 is... :) che il sensore dei cellulari fosse di pochi 

mm, con altissima densità di pixel e quindi scarsa qualità al di fuori 

delle condizioni ottimali è esattamente quello che stavo sottolineando 

io...


 discreto e non continuo.



:-)

Non e' un problema di classificazione o di segmentazione, e' il problema di misurare quanto grosse sono le bande. Non puoi considerare un modello binario barra/background per via del partial volume effect. Devi comunque lavorare su una grid che quantomeno soddisfi i vincoli di Nyquist. Ti tocca interpolare e regolarizzare l'immagine comunque. La regolarizzazione secondo Tikhonov e' puo' essere considerata (in alcuni casi, ovviamente) identica a smussare con un gaussiano.




 all'industria, e queste cose le vedo quotidianamente.



"queste cose"=?

Anch'io le vedo quotidianamente, da una decina d'anni ormai (il tempo vola). Applicazioni non industriali, ma in ambito medico, biomolecolare, e ultimamente militare.



 > messa a fuoco, giusto per tornare all'argomento iniziale, e' fondamentale.



m'era partito il post per la fretta.

dipende dall'algoritmo che usi, comunque la regolarizzazione e' d'obbligo se lavori con derivate ed invarianti. Differenziare una funzione "a step" e' un problema mal posto, quindi derivare e' un problema mal-posto (secondo hadamard), devi regolarizzare la funzione. In piu' se non regolarizzi ti ritrovi col problema del partial volume effect, che se vuoi quantificare la larghezza non e' affatto simpatico, specialmente se lavori al limite di Nyquist.

ciao.




 io...



okay. Ma per 20-30cm IMHO il suo dovere lo fa.

Basta ottenere una risoluzione spaziale di almeno 0.5mm/px (a voler essere cauti) e il problema si risolve. Se e' sfocato con un'ottica semi-decente,  l'immagine e' "regolarizzata", quindi hai un passo computazionale in meno da effettuare. Tutto qui.


 discreto e non continuo.



Ho provato a leggere il testo di Koenderink indicato da Askaholik. Nella sua complicata (almeno per me) trattazione matematica giunge ad identificare un equazione di "diffusione" dei pixel, identica formalmente a quella di diffusione del calore. 

Mi pare di capire che l'idea di base di Koenderink è che con successive sfocature ogni "blob" si dissolve progressivamente, alla fine resta solo un'immagine (un "blobbone") piena di pixel grigi uguali. Controllando con opportuni parametri le successive sfocature gaussiane, si possono classificare i diversi "blob". Da qui l'esempio dei ghiaccioli che faceva askaholik calza perfettamente (*)



(*) professor askaholik, ho studiato bene? :-))




 (*) professor askaholik, ho studiato bene? :-))



lol, prendi per il "phyb"? :-)


 lol, prendi per il "phyb"? :-)



No, era (semi)serio. Mi interesso di questi argomenti da qualche tempo, così mi piaceva avere un riscontro tuo, che ci lavori professionalmente, su quanto avevo capito. L'idea di Koenderink è indubbiamente molto interessante.

Oltre a quello di Perona-Malik, sai indicarmi un documento che spieghi come mettere in pratica queste idee nella classificazione dei blob? (magari un pò più "per dummies" matematicamente parlando :-)


 pò più "per dummies" matematicamente parlando :-)



IMVHO se vuoi capire il metodo devi leggere il documento originale che ho postato prima:

http://authors.library.caltech.edu/6498/1/PERieeetpami90.pdf


Riassunto riassunto, l'algoritmo smussa l'immagina con un kernel gaussiano isotropico con varianza proporzionale agli edges dell'immagine. In pratica se ci stanno edges (contorni marcati) smussa con un kernel molto piccolo (in pratica lascia l'immagine originale) se non ci sono contorni marcati, smussa l'immagine con un kernel piu' grosso (in pratica smussa l'immagine). Claro sin qui?

Ora, bisogna decidere se un pixel e' un pixel e' parte di un contorno marcato o meno, e questo e' definito dalla equazione 4 nell'articolo, in pratica utilizza il gradiente dell'immagine (la funzione c(x,y,t) ), nota che la funzione c restituisce un numero reale, non una matrice (!!!!), per algoritmi piu' recenti/complessi c e' una matrice ;-)

Questo e' tutto.

Tutto il resto, spiega come inserire la funzione c nell'equazione di diffusione, l'equazione 5 lo fa vedere nel caso di una dimensione. Per 2 o o piu' dimensioni, e' analogo. Nella sezione (V. EXPERIMENTAL RESULTS) mostra come discretizzare il processo, perche' tutte le equazioni spiegate prima sono nel continuo, e devono essere trasportate nel discreto. Tieni conto che questa sezione e' ormai obsoleta, perche' per ogni pixel tiene conto solo di 4 che lo circondano (sud, nord, est, ovest), in realta' le cose sono piu' complesse, come spiegato da Weickert (e altri) in quest' articolo:

http://ami.dis.ulpgc.es/biblio/bibliography/documentos/aos.pdf


Poi ci stanno altri dettagli sulla discretizzazione e sul time step, per velocizzare, me ne aveva parlato Weickert tempo fa, ma non ho avuto il tempo di guardarcivici e implementarlo :-) e' nella mia to-do-list, se ti interessa cerco l'articolo!

In pratica, come descritto dall'articolo di Perona-Malik funzia, ma ad essere pignoli ci stanno delle modifiche da fare, piu' o meno importanti. Occhio che wikipedia e' sbagliata sull'argomento, appena ho tempo devo sistemarlo:

http://en.wikipedia.org/wiki/Anisotropic_diffusion


Perona-Malik non e' un filtro anisotropico, e' isotropico inomogeneo, nonostante nel titolo dell'articolo lo chiamino isotropico (!!!) E' isotropico perche' ogni pixel viene smussato con un filtro gaussiano isotropico (!!!). La distinzione tra isotropico e anisotropico e' stata fatta qualche anno dopo la pubblicazione dell'articolo. Son comunque dettagli ;-)

Spero sia chiaro, se hai domande chiedi pure, se le so ti rispondo :-)






 Spero sia chiaro, se hai domande chiedi pure, se le so ti rispondo :-)



Ti ringrazio dei chiarimenti e della disponibilità, ora devo metabolizzare il tutto. (in effetti il metodo di P.-M. in molti siti è chiamato appunto diffusione anisotropica)


 (in effetti il metodo di P.-M. in molti siti è chiamato appunto diffusione anisotropica)



per diffusione anisotropica si intende la diffusione che privilegia una direzione anzicche' l'altra, e non e' il caso del P-M, che ha un kernel perfettamente isotropico. La diffusione P-M viene detta inomogenea perche' non e' costante, ma varia da pixel a pixel, dando l'effetto di smussare l'immagine preservando i contorni.




 perfettamente isotropico.



ovviamente si tratta di anisotropie locali, quindi la diffusione anisotropica privilegia *localmente* una direzione anzicche' l'altra, Che non e' il caso del P-M. 

Per la fretta mi ero dimenticato di scrivere "localmente", sorry.


 Nyquist.



Mettiamola cosi': se non sei a fuoco, non vedi un cazzo. 




 Mettiamola cosi': se non sei a fuoco, non vedi un cazzo.



cit. SS Inquisizione? :-)


 

<CUT>

Guarda... sviluppo su mobile da una decina d'anni e mi ritengo piuttosto competente nell'ambito, ma purtroppo, al giorno d'oggi, la realtà che mi si presenta davanti, è quella di aziende che sono alla costante ricerca di "polli da batteria" da poter spremere a piu' non posso, per un tozzo di pane.



E questo, nonostante la mia richiesta economica sia la medesima di 10 anni fa.

Ed è tutto molto sconfortante.



Dal mio punto di vista, le figure professionali non mancano... 

il vero problema oggigiorno, è che le aziende, pretendono di andare al ristorante, per cenare a base di ostriche, aragoste e champagne e spendere 15eur in due.



Un articolo interessante sull'argomento:

http://www.codeido.com/2013/02/lavorare-in-italia-come-sviluppatore/