Questa volta Vista l’ha fatta grossa! Dopo una pulizia del disco era scomparsa la modalità ibernazione e tutte le opzioni associate ad essa. È vero, la pulizia del disco elimina i file di ibernazione, ma non avrei mai immaginato che avrebbe disabilitato tali file necessari all’ibernazione o alla sospensione ibrida.

Il bug è noto, la soluzione si trova sul sito della Microsof stessa: apriamo il Propt di comandi come amministratori (è sufficiente cliccare sul destro sull’icona del Prompt dei comandi e scegliere Esegui come amministratore) e da li digitiamo:

powercfg -h on

Controllate: l’ibernazione sarà nuovamente selezionabile. C’è da notare che il SP1 l’ho scaricato ma non ancora installato, per cui non so se questo bug esiterà ancora dopo l’aggiornamento.

Vista, ibernazione, sospensione ibrida, scomparsa, bug

Popularity: 38% [?] Condividi

Oggi (finalmente) troverete fra gli aggiornamenti di Vista il Service Pack 1. Io lo sto già scaricando (sul portatile della mia ragazza) ma i server della Microsoft sono evidentemente sovraccarichi. Nel frattempo mi chiedo: ma che fine ha fatto il Service Pack 3 per XP?

P.S.= il portatile è tornato. Tutto ok, alla fine non ho dovuto pagare nulla perché era una cavolata che si sistemava in 2 minuti. Aspettare 33 giorni per 2 minuti… Davvero divertente.

- Warning: Divide by zero.

Vista, Service Pack, SP1, update, download, XP

Popularity: 19% [?] Condividi

Nell’ambito dello sviluppo di sistemi software mi è sembrato molto interessante il modello denominato eXtreme Programming (XP), un modello di sviluppo agile molto meno rigido rispetto ad altri metodi si sviluppo. Le parole chiave di questo questo approccio sono: semplicità, comunicazione e semplicità. In realtà, la prima volta che ho sentito parlare di eXtreme Programming mi sono immaginato a programmare con il portatile legato alla cintura mentre scalavo una parete…

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 “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.

eXtreme Programming, modelli di sviluppo, programmazione agile, software, sviluppo, XP

Popularity: 31% [?] Condividi

Sta mane, a distanza di 9 giorni, riappare la scritta R.T. sul mio cellulare. Prima di rispondere prendo un bel respiro e mi preparo al peggio (ma non a questo peggio). Peccato che riportando questo dialogo come testo non si percepisca la freddezza della mia voce che ho mantenuto per (quasi) tutta la telefonata.

R.T. : Ciao Vincenzo, ho una notizia buona e una cattiva. Quella buona è che ti hanno cambiato sia la scheda madre che il masterizzatore DVD. Quella cattiva è che… che non funziona comunque.
Io: Come? E quindi?
R.T.: Quindi… Pare che sia l’alimentatore.
Io: E questo me lo ero immaginato si dall’inizio. Ma, scusa, non l’avevano provato prima di cambiare tutta quella roba?
R.T.: Veramente l’hanno provato, sembrava che erogasse corrente nei livelli corretti.
Io: Ma non vuol dire niente, cioè, non ne hanno provato un altro? Quanto gli ci voleva?
R.T.: Non lo so Vincenzo, ma non puoi prendertela con me.
Io: No, no, infatti. Evidentemente la mia fiducia nella Toshiba era mal riposta.
R.T.: Ehm… La brutta notizia non è ancora finita. Quelli di Milano mi informano che il cavo dell’alimentatore è evidentemente maltrattato, quindi non è coperto dalla garanzia [Qui ci vuole una doverosa nota. Io ho sempre trattato il mio portatile come un figlio e in ugual modo l'alimentatore. L'unico problema riscontrabile è che mi si è staccato il laccetto che serviva a legare il cavo quando non usavo l'alimentatore.]
Io: Che cosa? Ma… Lasciamo perdere. Quanto mi verrà a costare?
R.T.: Senti, io lo faccio tornare qui e lo do ad un mio tecnico di fiducia. Se riesce ad aggiustarlo te la cavi con 20-30 €, altrimenti sono 70 € di alimentatore nuovo.
Io: Ok, grazie.

Evidentemente questo portatile è stato il mio primo ed ultimo Toshiba. Se il prossimo portatile dovessi sceglierlo in base all’affidabilità dell’assistenza tecnica allora sarebbe un Dell. Faccio un esempio di esperienza diretta: un Dell con un tasto rotto della tastiera. Chiamata l’assistenza e, spiegato il fatto che quel portatile serviva per lavoro di tesi, ci inviano a casa la tastiera di sostituzione. Esattamente 24 ore dopo, arriva il pezzo con corriere UPS. Richiamiamo l’assistenza e troviamo un tecnico informato dei fatti e disponibile a spiegarci il processo di sostituzione rimanendo al telefono mentre siamo all’opera. Tutto a buon fine, la tastiera rotta parte con un altro corriere UPS, sempre a carico della Dell. Tutto risolto in una giornata. Contando che io sto aspettando da 22 giorni (e mi tocca anche pagare)… Addio Toshiba.

- Warning: Divide by zero.

===
Crediti immagine: Toshiba - 45 dies by vdbdc

Techorati tags: Toshiba, addio, garanzia, affidabilità, Dell,

Popularity: 12% [?] Condividi

In questa settimana di no-notebook mi sono dedicato a rimettere ordine le mie cose (qualcuno gridava al miracolo). È così che riscopro un piccolo museo delle anticaglie da cui estraggo il mio primo scanner, un Mustek 1200CP. Dopo averlo ripulito dai diversi strati di polvere che lo ricoprivano mi trovo davanti al fatto che su Windows XP non ha nessuna intenzione di funzionare. Ho, quindi, tentato di farlo lavorare su Ubuntu e, contro ogni mia aspettativa, ci sono riuscito! Anzi, è stato ancora più facile di quello che pensavo.

Per prima cosa scarichiamo i file del progetto SANE (Scanner Access Now Easy), digitando da terminale:

sudo apt-get install sane sane-utils

e quindi controlliamo che il nostro scanner sia rilevato:

sane-find-scanner -p

Se nel testo che compare nel terminale è presente il seguente,

# Your Mustek parallel port scanner was detected.  It may or
# may not be supported by SANE.  Please read the sane-mustek_pp
# man-page for setup instructions.

significa che lo scanner è stato riconosciuto, bisogna svolgere solo due piccoli passaggi per configurare SANE correttamente. Primo: modifichiamo il file dll.conf:

sudo gedit /etc/sane.d/dll.conf

in cui cercheremo la riga contenente mustek_pp ed eliminiamo il carattere #, quindi salviamo e chiudiamo. Infine bisogna informare SANE del modello del nostro scanner:

sudo gedit /etc/sane.d/mustek_pp.conf

scorriamo fino in fondo al file ed eliminiamo il carattere # antecedente la riga del nostro modello, nel mio caso scanner Mustek-1200CP 0x378 cis1200.

A questo punto è sufficiente lanciare Gimp (Applicazioni > Grafica > GIMP) e dal menù File scegliamo Acquisizione > XSane > Device Dialog. Si aprirà la finestra di dialogo per effettuare le scansioni: ecco come appare nel mio disordinato desktop:

Clicca sull’immagine per ingrandire

Sono quasi commosso…
- Warning: Divide by zero.

Technorati tag: scanner, Mustek, 1200CP, Ubuntu

Popularity: 29% [?] Condividi