Back to top

Visualizza post

Questa sezione ti permette di visualizzare tutti i post inviati da questo utente. N.B: puoi vedere solo i post relativi alle aree dove hai l'accesso.


Post - marco.delpercio

Pagine: [1]
1
Sviluppo / Nuovo plugin 1Pixelout Audio Player 2.0
« il: 16 Ago 2010, 13:45:41 »
Salve

Non so se conoscete il plugin 1pixelout player per Joomla, è una estensione scritta da Duvien Trang con un flash player per riprodurre mp3 sotto forma di plugin joomla. Lo sviluppo di quella estensione era stato abbandonato dall'autore che è passato (ahimè) a Drupal...siccome per un progetto personale mi serviva di arricchirlo di alcune features l'ho ripreso e rifatto e poi ho contattato l'autore per condividere con lui la nuova versione del plugin. Oggi viene pubblicato 1pixelout audio player plugin 2.0 per Joomla ( http://www.duvien.com/blog/1pixelout-audio-player-2-plugin-joomla ) il cui sviluppo è dunque totalmente Italiano per opera mia.

Scrivo questo post non tanto per pubblicizzare la cosa (come molti di voi malpensanti stanno già facendo :) ) quanto per scopi puramente didattici, infatti (spero che possa interessare) ho riscritto il plugin in maniera tale che fosse compatibile sia con Joomla 1.5 che contemporaneamente con la nuova Joomla 1.6, obiettivo raggiunto grazie a qualche piccolo accorgimento che può essere esteso anche ad altre estensioni (è questo ciò che vorrei condividere).

Ora non so come fare poiché sebbene il plugin originale fosse free, l'autore Duvien ha suggerito di rendere il nuovo plugin un estensione donationware, con una donazione (solo la prima volta) di 3$ (circa 2.3 €). Capirete che per quanto ridicola sia la cifra richiesta da Duvien io non posso pubblicare qui l'archivio zip del plugin poiché verrei meno alla promessa, però al tempo stesso vorrei che gli sviluppatori italiani di estensioni ( se non ne sono già a conoscenza ) possano sfruttare gli stessi accorgimenti per le proprie estensioni.
Se la cosa interessa a qualcuno posso pubblicare in un post successivo i dettagli del file xml del plugin e la directory structure

Marco Del Percio

2
esatto jacko infatti è proprio quello che volevo mettere in evidenza con quelle varie alternative... il metodo basato solo su intervalli di tempo non è sufficiente e non è sufficiente nemmeno quello sulla "rilevanza" dei componenti....in quel post cercavo di dire ke sul piatto della bilancia pendono tante cose: aspetti di sicurezza, priorità, rilevanza, frequenza,competenza, trasparenza... e se hai letto i post precedenti avrai inteso anche tu che non è sempre facile scegliere in maniera ottimale. Lo scopo di questo topic è quello di delineare una metodologia che ci aiuti ad operare le scelte migliori. Tu come fai ad esempio?

Per quanto riguarda gli update di sicurezza... o come li chiamo io gli aggiornamenti "asap" siamo tutti d'accordissimo non si discute vanno fatti al più presto e rientrano nel compenso forfettario destinato alla manutenzione.

3
Ah ecco, allora in tal caso è ben diversa la cosa. Beh come tutti i preventivi il cliente ha il diritto di valutarlo o farlo valutare ad un esperto e/o eventualmente confrontarlo con altri preventivi ed infine scegliere.
io, a tutte le domande poste da sudoku,  e ad altre, ho risposto nel mio preventivo indicando nel dettaglio ciò che avrei fatto ed evidenziando ciò che sarebbe dovuto essere stimato a parte, come il web marketing
è assolutamente giustissimo, non è necessario lamentarsi e "farlo valutare ad un esperto" non significa certo chiedere sul forum. Il cliente è libero di fare preventivi altrove facendo però attenzione che non è solo il prezzo più basso l'indicatore principale. Non stiamo vendendo materie prime che sono quotate dal mercato internazionale, "quanto costa 1Kg di mele?" no non è così banale, esistono numerosi modi di realizzare un sistema web che rispecchi i punti di quella lista, anche con metodi non basati su CMS...è chiaro che ognuno ha vantaggi e svantaggi e chiaramente costi diversi. Come ha detto 56francesco ritengo che sia una trattativa privata e come tale non credo che il forum possa esservi molto d'aiuto, servirebbe solo a risvegliare vecchi discorsi e generare polemiche.

4
non sentivo parlare di gestione del software dai tempi della scuola, dove si faceva tutto con la teoria, una volta arrivato nel mondo del lavoro scopri che tre anni di studi non sono serviti a niente.

Non so perché dici così, anche io all'esame di ingegneria del software pensavo che fossero boiate ma poi crescendo ho scoperto che quelle "boiate" ti possono salvare perchè sono il frutto di tanta esperienza di gente con le palle e credimi, serve e come!

...versione di joomla 1.5.12 che il cliente non vuole aggiornare poichè ha a disposizione il vecchio editor e installando quello nuovo si dovrebbero riconfigurare tutti gli articoli che sono stati creati in precedenza.
perdonami non credo di capire...non vorrei banalizzare il tuo problema ma in che modo gli articoli già fatti in  si legano all'editor? E' solo codice DHTML già memorizzato nel db, codice che sicuramente il nuovo editor saprà interpretare...

Cosa bisognerebbe fare in questo caso?
;D credo che mau ti direbbe di "godere come un riccio" attendendo il deface, dico bene? No sul serio, io mi preoccuperei principalmente di spiegare al cliente che data la versione del suo CMS si espone a rischi di sicurezza piuttosto gravi, se non riesci ad aggiornare perché non vuole ...il tuo lavoro è terminato; se non riesci ad aggiornare per motivi tecnici devi trovare tu una soluzione a patto che te la paghi in maniera commisurata, se riesci ad aggiornare...il tuo lavoro è ugualmente terminato.

ma visto l'economia oggi giorno, credo che bisogna prendersi tutto ciò che si trova, da un sito di 100€ fino ad un sito di 1000€
Piano! E' vero che i tempi sono duri....ma questo non significa che devi fare le aste al ribasso svendendoti! é male per te e fa scendere il valore delle cose! Se inizi ad accettare tutto, sarà difficile far salire il valore delle cose che fai.

Spero di essere stato di aiuto

5
Aspetta :) fammi capire bene...  :D il vostro rapporto è stato: tu mandi una mail con un elenco numerato di una decina di voci (quelle voci lì)... e questo viene trasformato in un preventivo da 2000 €? Il tutto senza le domande che ha evidenziato sudoku?
Si potrebbe mettere su un servizio List2money.org ;D


6
Si, è vero le vivo male perché quello che hai scritto tu

"devi semplicemente e chiaramente stabilire cosa fai tu e a che prezzo"

non è poi così semplice da far capire al cliente che spesso non capisce un tubo...non è così banale, tu la fai troppo facile mau, evidentemente i tuoi clienti hanno atteggiamenti molto diversi.

Ad ogni modo quindi riassumendo il tuo metodo è:

"Vengo pagato un forfettario per garantire NO PROBLEMI poi qualsiasi cosa succede me la vedo io. E questo forfettario lo stabilisci in base alla complessità del sito."

dico bene?


7
Ok forse è meglio, cmq no non sto parlando di manutenere l'mvc, quella è una metodologia per lo sviluppo... e sappiamo bene che in Joomla e le sue estensioni è già applicato. Io parlo di metodologie per la manutenzione. Ti faccio alcuni esempi di problematiche concrete per le quali io ritengo che ci debba essere una metodologia o un criterio, spero di essere chiaro:

Un problema banale e comune: Scegliere la frequenza
Prendi il progetto di un tuo cliente, in base a cosa scegli la frequenza con cui effettuare degli aggiornamenti al sistema?
  • In base al tempo? (Es. 3 volte al mese)
  • In base al numero di estensioni installate? (un progetto senza estensioni va certamente soggetto a meno aggiornamenti di uno con 50 componenti)
  • In base all'impatto delle estensioni installate sul progetto specifico? (Es. un progetto e-commerce ha certamente più bisogno di tenere aggiornato Virtuemart e le relative estensioni/personalizzazioni poiché Virtuemart per progetti e-commerce è un'estensione business critical)
  • In base alla sola priorità dell'aggiornamento? (Es. una cosa la aggiorno solo quando sarò costretto perchè esce un security fix, altrimenti che mi frega)

Un problema comune: la trasparenza col cliente
Sicuramente anche tu avrai dei contratti di manutenzione per progetti Joomla. Tu comunichi al cliente cosa aggiorni e quando? E se si come fa il cliente che non è un tecnico a fidarsi di quel che gli dici? Proprio ritornando a quei montati di testa che non capiscono una cippa come dici tu... io potrei barare col cliente e dire che ogni mese è necessario fare 1 aggiornamento di sicurezza, come fa il cliente a contraddire? Si deve fidare e basta? Le banche non fanno così ad esempio. Ti mandano per posta mensilmente l'estratto conto col dettaglio dei movimenti, questo è un documento che può capire anche un utente comune. Secondo me (ma è una mia personalissima idea) ci vorrebbe il modo di generare un report in back-end simile a quello del com_install con le versioni e la data di installazione per tutte le estensioni non-core, però in un'altra colonna dovrebbe essere possibile reperire da remoto l'ultima versione della stessa estensione... (si lo so, probabilmente si può barare anche così... è solo un'idea di partenza) le estensioni dovrebbero avere dei feed online riguardo l'ultima versione disponibile, sarebbe tutto più facile.

Un problema di scelte: Risk Analysis
Supponiamo che tu hai il tuo progetto Joomla con N estensioni e ogni X mesi fai un aggiornamento generale.  Un bel giorno durante un aggiornamento generale scopri che l'ultima versione di un modulo causa dei conflitti ( es. col tuo template, con un componente, con altri moduli). Per conflitti intendo un generico problema: il tipico conflitto di librerie javascript oppure l'ultima versione necessita di una certa versione di PHP che il tuo hosting non raccomanda o non supporta, oppure ti sputtana il layout del template...
Che cosa fai? A me quando è capitato ho cercato di intervenire a manina nel js o nel php ecc...a volte è stato possibile sistemare, ma altre volte no...codice offuscato o packato. E allora l'analisi dei rischi è quella che fa valutare le varie opzioni: Conviene intervenire a mano? E se lo faccio poi devo sempre ricontrollare le versioni future? E' possibile sostituire quella estensione con un'altra? E se si, conviene? E la nuova estensione sta bene al cliente?
Con quali criteri prendi questa decisione?

Queste sono le prime 3 cose che mi sono venute in mente perché le ho vissute sulla mia pelle e le vivo tutt'oggi, penso si tratti di cose con cui hai avuto a che fare anche tu sicuramente. Mi potrai dire che sono cose che impari a gestire con l'esperienza...le metodologie servono proprio a questo :) .

8
Ma perchè finiamo a parlare d'altro con sfoghi vari e toni così accesi? Cioè mi fa piacere condividere esperienze per carità se vuoi continuiamo a parlarne ma le cose che hai detto sebbene siano giustissime e le condivido pienamente non sono oggetto di questo topic. Guarda sul serio non c'è persona + d'accordo di me quando si parla di script kiddies e simili però io non ho alcuna intenzione di scrivere una guida "dummy" per nessuno. Sto cercando di dirlo dal primo post ma pare che solo alexred abbia capito qual'era il mio intento.

Vi prego di rileggere il mio primo intervento di questo topic, evidentemente sono io che non mi spiego, proverò a ripeterlo con altre parole:

Io non sto parlando di guide TECNICHE per fare la manutenzione, sto parlando di METODOLOGIE, di Ingegneria del Software. Siccome per altri ambienti come quello Java esistono una caterva (molti) approcci e diverse metodologie che riguardano il ciclo di vita e manutenzione del software, io voglio sapere se esistono metodologie/processi già consolidati anche per i sistemi web basati su CMS ed in particolare per Joomla. Se non è stato proposto nulla di tutto ciò vorrei mettere insieme le diverse esperienze per cercare di tirar fuori una metodologia/processo di manutenzione ottimale, che può servire a tutti.

Per fare un esempio...sto cercando qualcosa tipo il RUP di IBM ma che riguardi sistemi Joomla e sto dicendo che se non esiste secondo me sarebbe proficuo per la community. Chi non lo capisce può continuare a premere i bottoni o fottersene ed adottare il suo particolarissimo metodo. Ma se in altri ambiti (con altre tecnologie) lo hanno fatto, un motivo ci sarà? :-)



9
Correggimi se sbaglio mau, credo di capire le tue motivazioni, tu sei un esperto di sicurezza e giustamente trai profitto da quei progetti in cui diciamo un "processo mal gestito" ha causato una magagna.
E' giustissimo questo, assolutamente giustissimo, non voglio combattere questa cosa, credo che indipendentemente dallo standardizzare i processi di manutenzione o meno... i bug ci saranno sempre e così gli exploit e tutto, forse tu pensi che potrebbe ridurre il tuo mercato?

10
Mau non ci siamo capiti...ascoltami, non voglio fare polemica rifletti un attimo...non banalizzare quelle 2 cose che hai scritto e che sono importantissime.
Altrimenti le linee guida della tua banca che gestice il conto corrente  si ridurrebbero a

-non far pagare troppi soldi

è facile così ma dietro questo ci sono persone che si fanno in 4 per "gestire il tuo conto" o per "tenere aggiornati i componenti" e soprattutto non basta quello che hai detto perché ci vuole anche trasparenza col cliente, è troppo comodo dire "Dammi tot € al mese e me la vedo io per tutto"...proprio perché se sono uno di quelli che si spaccia x capace...sto truffando il cliente e quando succederà un casino... magari il cliente pensa "Ma sto sito in Joomla mi costa troppo, mò lo faccio rifare ad 1 altro in 1 altra tecnologia"  ;) . Non pensiamo alle cazzatelle disinstalla e installa il nuovo. Se banalizziamo (così come farebbe il cliente ignorante...) è Joomla che ci perde la faccia e (almeno) io che tutt'oggi sto puntando su questo strumento come te e gli altri NON VOGLIO CHE QUESTO ACCADA.

Anche a me fa "piacere" quando defacciano uno che se ne frega degli aspetti di sicurezza (si, :) lo ammetto 1 pò sadicamente penso "ben gli sta" :P). Però così è il caos...e non va a vantaggio di nessuno. Non credi?

11
Signori perché non iniziamo a concretizzare man mano queste linee guida? Potrebbero servire a tutti io credo...Inizio io stesso se volete, nei prossimi giorni (compatibilmente con gli impegni tanto non ci corre dietro nessuno) inizio a scrivere un draft...di un processo di manutenzione generico, che possa adattarsi a diversi tipi di progetto. Sarei lieto se questa cosa si arricchisse con i vostri consigli e le vostre esperienze. Che ne pensate?

12
Ciao Mau

è vero certo hai ragione, è chiaro che il processo standardizzato non è un must, non volevo intendere che va "imposto", il cliente che se ne frega è libero(ne ha tutto il diritto) di fregarsene (come diceva giustamente 56francesco, a insistere coi tipi così è inutile e si diventa solo antipatici), tuttavia quantomeno l'esistenza di una base/linea guida del processo di manutenzione ti da almeno il deterrente del dire al cliente "esiste questo modus operandi per fare le cose per bene...poi sei libero di seguirlo a testa tua o di fregartene proprio".

Per fare un paragone calzante con l'esempio che hai fatto...la casa automobilistica di fatto lo fa già quello che sto dicendo, infatti non so se ti è mai capitato di acquistare una autovettura nuova ma la casa madre rilascia un vero e proprio libretto che si chiama di "manutenzione programmata" dove ci sono le scadenze e cosa dovrebbe essere revisionato ogni tot Km. Quindi come vedi anche loro fanno così, certo nulla vieta che tu a quel libretto gli dai fuoco appena uscito dalla concessionaria :) è una tua scelta, ma la casa automobilistica ti ha detto come dovevi fare per non avere sorprese. Io penso che anche coi sistemi web (in particolare quelli basati su CMS) dovrebbe valere la stessa cosa.

13
C'è un mio collega che dice sempre che "gli informatici non fanno soldi come medici o avvocati perché sono i muratori del terzo millennio, non hanno qualcosa che eguagli -l'ordine dei medici- o -l'ordine degli avvocati-"  :D io ci scherzo su però credo che abbia ragione in fondo, molti di noi, specie i più giovani (è successo anche a me all'inizio) si svendono e magari non sanno manutenere un sito, altri si spacciano per padreterni e offrono lo stesso servizio...ma la cosa peggiore è che il cliente spesso non è in grado di fare la differenza!...Che sia perchè la variabile manutenere_un_sito = ? non è stata mai definita con criterio :-) o comunque se ne parla poco fra di noi?

14
...il tipo b va da se che si preoccupa che il suo strumento di lavoro sia efficiente e sicuro non serve insistere

Caro Francesco ;D eppure ti giuro che ho clienti con Virtuemart che hanno un concetto quasi "mitologico" dell'hosting e quasi fantascientifico del CMS...non hanno idea di cosa comporti mantenere il loro strumento "efficiente"...però una cosa la sanno bene... quanto sono disposti a pagare e a volte se ne fregano ampiamente... perché per loro conta solo il prezzo dei prodotti magari.

15
Scusa ma intendi 2 o 3 al mese per ciascun progetto? Fai proprio questo per vivere evidentemente  :) purtroppo Joomla non è il mio impiego principale... se avessi una frequenza così alta per ciascun progetto forse riuscirei a camparci  ;D
Inoltre riflettevo che è vero così è possibile auto-gestirsi ma ci sono degli update che magari vanno fatti alla svelta (security fix) e invece update di cui al cliente non frega molto e non cambiano la vita del sito (es. viene rilasciata la nuova versione di 1 componente che ha come cambiamenti solo delle nuove features che tu magari non usi). Gli update dovrebbero avere una "priority" diversa a seconda dei casi e di conseguenza "pesi" diversi.
Non so... probabilmente raccogliendo best practice dai vari webmaster si può tirar fuori un processo ottimizzato, pensi sia positivo o credi sia una cosa estremamente soggettiva?

16
Ciao alex e grazie per partecipare...ho letto spesso tuoi post :-) ma come si capisce evidentemente io non partecipo spesso al forum.
Ascolta ma il quanto annuo mi pare di capire che è una cifra forfettaria, dico bene?
Questa è una cosa che ho provato anche io ma ti può anche andare male...voglio dire...tu garantisci x tutto l'anno e quanti interventi fai? Non puoi saperlo a priori. Il forfettario dovrebbe essere proporzionale al numero e al tipo di estensioni installate che a sua volta può mutare nel tempo...


17
nella misura in cui
 ;)
lo sa già di suo

Perdonami ma non capisco cosa vuoi dire...non so che clienti abbiate dalle tue parti :-) ma qui diciamo 4 su 5 ignorano assolutamente la problematica. Ho visto clienti ignoranti dare la colpa al webmaster per molto meno ...il topic vuole solo essere oggetto di confronto con gli altri. Come dicevi prima c'è chi pensa che tutto sia dovuto sempre gratis. Come fate a far ragionare clienti del genere? Io c'ho riflettuto nel tempo e credo che la soluzione sia avere un processo unico, magari certificato, rafforzato dalle esperienze di tutti noi e che sia simbolo di qualità. Per questo ho aperto il topic.

18
Nono nessuno sfogo, forse sono stato frainteso...immaginavo solo che potrebbe essere importante avere un processo di manutenzione standard... per tutti quelli che lavorano con Joomla con un criterio. Non so... invento...si potrebbe condividere col cliente una lista dei componenti/moduli/plugin installati e rispettive versioni (anche del cms), disporre di un modo standard per stabilire sempre quanto si è indietro con una certa estensione, così che il cliente possa rendersi conto di quanto invecchia il sistema e magari rilasciare al cliente un documento di quality dove sono elencate le versioni dei componenti aggiornati e/o i bug corretti e/o le customizzazioni, la data dell'ultimo backup...voglio solo sapere se tutto questo ognuno qui lo fa a modo suo? O tenete sempre silenziosamente aggiornato tutto senza dire niente al cliente? (mi auguro proprio di no) Insomma in che modo fate capire al cliente quanto è importante aggiornare?

19
Salve

E' ormai dai tempi della 1.0 che ho a che fare con clienti e progetti di varia natura... sempre più spesso basati su Joomla.
Per le esperienze che ho potuto fare, uno dei passi più critici è spesso quello di far capire ai clienti che un sistema come questo non è un bel dipinto che, dopo il rilascio in produzione, si appende lì e non lo si tocca mai più, bensì si tratta di un qualcosa di sofisticato che indipendentemente dal CMS va aggiornato e soprattutto monitorato (sto parlando ovviamente di progetti medio-grandi).
Proprio qui nascono gli scontri di vedute poiché non tutti capiscono l'importanza del processo di manutenzione...secondo me la tecnologia va avanti e non aspetta nessuno, si evolve il CMS ma anche le sue estensioni e non solo... si evolvono i browser, le tecnologie su cui si basa il CMS,
cambia la versione di PHP, di Apache, escono le nuove API di Google o Facebook o Youtube...e tutto questo non va sottovalutato per un progetto serio.
A questo punto mi chiedevo (siccome io lavoro nel mondo Java) se anche nel mondo dei CMS ed in particolar modo di Joomla esiste uno standard per questo processo di manutenzione/evoluzione. Non sto parlando di questioni squisitamente tecniche ma di Ingegneria del Software, chi l'ha studiata sa quanto è importante un processo di manutenzione controllato e come si colloca nel ciclo di vita del software.
Non so se già esiste questa cosa ma secondo me...sarebbe importante standardizzare (con documentazione, contratti, versioning) il processo di manutenzione di un sito o di un'applicazione
web Joomla based, secondo me è lo stesso motivo per cui quelli di Rational alla IBM hanno avuto successo con la tecnologia Java.

Perchè è importante?
E' importante per il cliente: perché così capisce la differenza fra un sistema abbandonato a se stesso ed uno up to date, perché in
questo modo c'è trasparenza e sa cosa è installato, in un qualche modo ha la "garanzia" che non ci saranno sorprese.
E' importante per voi/noi (webmaster) perché in questo modo sappiamo cosa andrebbe aggiornato per ciascun progetto e quantificando si può
pianificare l'aggiornamento e stabilirne la complessità...e il prezzo.
E' importante per la reputazione di Joomla e della community: quanti siti sono stati defacciati per componenti non aggiornati o dichiarati vulnerabili? Vi ricordate quando uscì il bug del cambio password verso la 1.5.15 (...mi sembra se la memoria non mi inganna)? ...Questa gente poi è quella che abbandona Joomla o lo etichetta come non sicuro che invece è una cazzata! perché se ci fosse stato un processo controllato con qualcuno che avesse detto ai clienti "c'è un aggiornamento immediato da fare, pena la sicurezza del sito" allora si scopre che non è colpa di Joomla(non tanto) ...quanto piuttosto della negligenza di chi amministra lo specifico sito o del cliente che se n'è fregato.

20
Joomla! 1.5 / Re:[RISOLTO]problema menu e sottomenu
« il: 18 Apr 2010, 12:04:10 »
Mi spiace vedere questo topic e l'omonimo Inglese con così tanto ritardo. Ragazzi io ho implementato una soluzione poiché avevo il medesimo problema. Non ho installato moduli poiché volevo continuare a gestire tutto col core del CMS preservando lo stile del mio template.
Desideravo condividere con voi la soluzione, perciò mi sono registrato. Ho postato la soluzione nel forum inglese

http://forum.joomla.org/viewtopic.php?p=2113917#p2113917

Spero sia di aiuto a chi (come me) voleva fare questa cosa e non ci era riuscito

Saluti
Marco Del Percio

Pagine: [1]


Web Design Bolzano Kreatif