Usare @font-face è semplicissimo: carichiamo un font a nostra scelta nel tema di WordPress, ad esempio il bellissimo Bleeding Cowboys (lo vedete in azione nel logo di “viklog”).  Dopo di che modifichiamo il foglio di stile nel seguente modo:

@font-face {
	font-family: Bleeding Cowboys;
	src: url('Bleeding_Cowboys.ttf');
}

A questo punto possiamo utilizzare il font come tutti gli altri, per esempio:

h1 {
	font-family: "Bleeding Cowboys", Georgia, serif;
}

L’utente che accederà al nostro blog vedrà senza problemi il font perché questo verrà automaticamente scaricato e installato nel sistema.

Bene, qual’è il problema? Molto semplice: noi stiamo ridistribuendo il font, abbiamo il diritto di farlo? Nel caso di Bleending Cowboys c’è una generica licenza “Free for personal use”, un po’ vaga; ma credo che l’uso personale escluda la ridistribuzione del file. Prendiamo un altro font, gratuito anche per uso commerciale: Delicious. Nella licenza si legge chiaramente:

• This font is free for personal and commercial use
• The font file/software may be modified to suit design of system requirements,
  but strictly for your own (personal or commercial) use. You may not sell or distribute it
• Embedding (in PDF’s, Flash files and programs) is allowed

[...]

Quindi: è vietato vendere o distribuire il font, ma può essere incluso in file Flash, programmi o PDF. La soluzione a questo problema è usare sIFR. In ogni caso vi consiglio caldamente di leggere sempre le condizioni d’uso di un font prima di utilizzarlo in un progetto – sia esso online o su carta – soprattutto se tale progetto è destinato ad un vostro cliente.

Nessun articolo correlato.

Un amico di un amico di un amico mi ha detto che tu aggiusti siti [si, aggiusto siti]. Vedi, il nostro sito ha una sezione di back office [e che cazzo sarebbe?] che fino a ieri funzionava, ora non funziona più…

Ieri funzionava, oggi no. Ovvero errore 500. Quello simpatico simpatico. Poi si è scoperto che una query restituiva una quantità  di contenuti da elencare nella pagina così abominevole che la suddetta pagina superava i 14 MB, indi per cui Aruba ne bloccava la generazione. Fra le altre cose, non capisco perché la gente si ostini ad usare Aruba…

Come dicevo nel titolo a volte può essere divertente. Quando mi trovo di fronte a codice HTML/CSS/PHP/Js/etc etc ben strutturato e, magari, ben commentato. Spesso mi è successo di imparare da questo qualcosa di nuovo.

A volte può essere divertente…

Un commento molto eloquace

…altre no.

• Pagine con stile a tabelle. Unica soluzione: CTRL+A, DEL, CTRL+S (metodo che mi piace chiamare brute code refactoring)
• Stile e contenuti all’interno dello stesso file. Magari ogni pagina diversa dall’altra.
• Pagine scritte con Word…
• Sezioni di amministrazione senza login.
• Login fatti con javascript che includono all’interno del codice della pagina la lista dei nomi utenti e password possibili in chiaro.
• Sessioni https con certificati scaduti da un anno.
• …

C’è qualcuno che ne ha viste di peggiori? Chissà  perché immagino di si.

Nessun articolo correlato.

extreme programming 5 by exacq

Per capire di cosa stiamo parlando, vi elenco in breve alcune delle pratiche che caratterizzano XP.

XP pratices

• Planning game: è la pratica che trasforma la classica analisi dei requisiti in un “gioco”. Si basa sulle user stories, descrizioni in linguaggio naturale di ciò che l’utente vuole che il software faccia.
  • Ad ogni user story gli utenti stessi assegnano una priorità , mentre gli sviluppatori un costo.
  • Ovviamente si tratta di una pianificazione informale
• Small release: si sviluppa i vari moduli del sistema software in modo incrementale, ad ogni ciclo si fanno piccole release.
• Whole team: tutto il team partecipa a ciascun aspetto dello sviluppo software in qualche modo.
• Collettive ownership: deriva dalla pratica precedente; la proprietà  intellettuale del codice appartiene a tutto il gruppo.
• Metaphore: per descrivere una funzionalità  del sistema software nel gruppo si usa una metafora. Ad esempio, per descrivere un gruppo di agenti software in azione si usa “lo sciame di piccole api volano sui fiori e rientrano all’alveare solo una volta terminato il loro compito”. Aiuta a far sì che il team usi un sistema comune di nomi di entità , tale che sia immediato trovare, per uno sviluppatore, una certo modulo in base al nome, o sia chiaro dove inserire le nuove funzionalità  appena sviluppate.
• Test-Driven Development: si scrive il codice sulla base dei test stessi. In poche parole si scrivono prima i test, poi si sviluppa l’applicazione finché non supera positivamente il test.
  • Questo processo è sempre accompagnato da xUnit (jUnit, cUnit, …)
• Refactoring del codice senza pietà! Uno dei motti del XP è “se un metodo necessita di un commento, riscrivilo!” (codice auto-esplicativo).
• Pair programming: si programma in coppia, il driver scrive il codice mentre il navigatore controlla il lavoro del suo compagno in maniera attiva.
  • Statisticamente è risultato un ottimo approccio nello sviluppo software, nonostante possa sembrare uno spreco di risorse umane
• Coding standard: a causa del Pair programming e Whole team si è reso necessario il raggiungimento di convenzioni di codifica fra gli sviluppatori.
• Idealmente il cliente è sempre disponinibile, in ogni fase del processo di sviluppo. Se gli sviluppatori hanno un dubbio, si rivolgono direttamente a lui.

Follia o realtà?

Posso dire, per esperienza diretta, che alcune di queste pratiche (come Test-Driven Development e Coding standard) sono delle ottime linee guida per scrivere codice di qualità. Altre, invece, mi sembrano delle vere e proprie follie. Basti pensare al 13^o principio: a inizio di ogni giornata si svolge una riunione di 15 minuti fra tutti i componenti del team di sviluppo, in cui ognuno espone cosa ha fatto il giorno prima, cosa pensa di fare quel giorno e le problematiche affrontate. Questa riunione si svolge rigorosamente in piedi, in modo tale che nessuno di dilunghi in inutili chiacchiere. Evidentemente questo sembra più una sorta di terapia di gruppo.

Negli USA questo modello di sviluppo software sta riscontrando grande successo, sopratutto nelle software house che dispongono di “carne fresca”. In Italia, invece, non credo esista un azienda che utilizzi questo modello, come sono pochissime le aziende che lo fanno in tutta Europa.

pair programming with duck by ysano

Vi lascio un paio di link sull’argomento:

• XProgramming.com – an Agile Software Development Resource
• Extreme Programming: A Gentle Introduction

- Warning: Divide by zero.

Articoli correlati:

1. Appunti di Ingegneria del Software – Modelli di processo software
2. Da PC a Mac: le alternative software e i freeware utili