Category: Software

Adobe Apollo…ops…AIR(r), Win 2000 e AttachConsole()

Qualche giorno fa ho installato la “alpha” di AIR, il nuovo ambiente di runtime cross-platform proposto da Adobe. Pur non avendolo provato (nel senso che non ho provato a sviluppare nulla), devo dire che sembra un ambiente molto interessante. In pratica consente di utilizzare HTML e Javascript per scrivere applicazioni che assomigliano un po’ a quelle Flash, ma che del player non hanno bisogno.

Ma veniamo al punto. Ho installato l’alpha, dicevo, praticamente solo per poter utilizzare [tag]tweet-r[/tag], un client di [tag]Twitter[/tag]. Tweet-r ha rilasciato oggi la sua versione 1.0 (direttamente dalla 0.76, un bel salto!), e si porta dietro come dipendenza l’aggiornamento del runtime di Adobe alla beta.

Senonchè, appena provo ad installare la beta di [tag]AIR[/tag], un bel messaggio mi informa che non è possibile trovare [tag]AttachConsole[/tag]() in kernel32.dll. Ci credo che non è possibile…quella funzione c’è in Vista, anche in XP, ma non in Windows 2000.

The procedure entry point AttachConsole could not be located in the dynamic link library KERNEL 32.dll.

Che dite, ci ripenseranno e produrranno un installer MSI per la piattaforma Windows (sì, perchè il problema sembra legato all’installer, non al runtime in se)? Oppure devo considerare WinXP un requisito?

UPDATE: c’è il solito, tempestivo Scooble che copre l’argomento, e soprattutto che sottolinea l’elemento più importante:

But, don’t miss the fact that Apollo apps no longer require Flash. They can be built totally in Ajax/JavaScript/HTML.

[tags]apollo[/tags]

ProgrammableWeb: API Listing (del.icio.us, Google Calendar, Twitter…)

Da qualche giorno ho salvato un paio di importanti risorse. E’ arrivato il momento di pubblicare il link (quando arriverà il tempo per poterci un po’ mettere le mani sopra?!?).
Nella lunghissima lista presente al seguente link trovate diverse decine di [tag]API[/tag], con le quali potete sperimentare la creazione di applicazioni. Ci sono quelle di Technorati, di MSN Spaces, di FeedBurner e vari altri ancora (del.icio.us, Google Calendar, Twitter, e non sono arrivato neanche ad un decimo della lista!).

Buon divertimento!
ProgrammableWeb: API Listing

[tags]ProgrammableWeb[/tags]

Ci vorrebbe un po’ di REST!

No, non mi riferisco al fatto che dovrei dormire di più! Anzi, credo proprio che le prossime settimane saranno da…meno di 6 ore a notte!
Mi riferisco al fatto che troppi, troppi progetti di [tag]interoperabilità[/tag] (nella Pubblica Amministrazione e non) vengono oggi sviluppati con un modello ([tag]SOA[/tag]) che benchè evoluto, presenta possibilità di rivoluzionario miglioramento. Forse possiamo chiamarlo SOA 2.0?
In tal senso l’architettura [tag]REST[/tag] permette già oggi, senza stratosferiche evoluzioni dei livelli sottostanti, di risolvere i principali punti critici dei sistemi di interoperabilità “aperti” (cioè quelli inter-aziendali), rendendo ancora più loose il coupling (bleah…! Appena riesco ad adattarlo in italiano…) fra i sistemi che devono interoperare.
[tags]web services[/tags]

NYC Hospitals | Health Care That Works

Che succede se applichiamo (in maniera intelligente) tecnologie moderne come quelle di [tag]GoogleMaps[/tag] e dei [tag]sistemi territoriali[/tag] ad un tema apparentemente scorrelato dalle informazioni geografiche come quello dell sanità? Succede che possiamo scoprire, ad esempio, che 8 dei 12 ospedali di New York City destinati ad una prossima chiusura o ridimensionamento si trovano in realtà nelle zone in cui il reddito medio è più basso.
NYC Hospitals | Health Care That Works

[tags]HealthCare[/tags]

Apparare i Capitoni

Nella gestione, già tipicamente complessa, di un progetto di realizzazione di un sistema informativo, la condivisione di un glossario comune a tutto il team di lavoro è uno step fondamentale. In realtà questo vale in pratica pre qualunque tipo di progetto. E se mi è concesso il paragone, una delle rappresentazioni più significative è forse disponibile nel
mondo della marineria e della vela in particolare, in cui, è noto, esistono decine e decine di termini per denotare i vari componenti ed accessori dell’attrezzatura disponibile a bordo di una imbacazione.
Ma torniamo ai nostri progetti IT. Nel confrontarmi (lo ammetto, qualche volta “scontrarmi”) col mio nuovo team di sviluppo napoletano, ho dovuto fare qualche sforzo per adeguarmi ad un linguaggio meno “accademico”, ma con interessanti spunti.
Scopro, parlando con il responsabile di uno dei componenti da sviluppare, che durante la fare di Transition (sì, perchè la metodologia di base è il RUP) è necessario “apparare i capitoni“. Devo dire che rende almeno quanto “bug fixing”. 😉
Da ciò l’idea di stendere un (divertente, spero l’intento sia chiaro) glossario di termini di project management “custom.

  • Apparare:
    mentre la traduzione principale potrebbe essere “preparare” (“Devo apparare la demo per lunedì!”), può anche essere inteso come “sistemare”. Da cui l’uso di “Apparare i capitoni” prima del rilascio di un prodotto (cfr. “capitone”)
  • Capitone:
    traduzione, anzi traslazione, visto che la natura dell’animale cambia, del “bug”, con riferimento ad un difetto del software che ne compromette le funzionalità e quindi la qualità (es. “La release e feature complete, ma naturalmente, trattandosi di una beta, qualche capitone nel codice sicuramente c’è”). La fase di “bug fixing” viene quindi definita di “apparamento dei capitoni”. Spesso si usa il diminuitivo “capitoncino”, facendo riferimento (ma non necessariamente) a bug di natura meno grave.
  • Sasicchione (o Sausicchione):
    Traduzione dall’italiano di “salsiccione” o “salsicciotto”. Usato come adattamento di vari termini tecnici, tutti facenti riferimento ad una sequesnza di byte. Ad esempio, usato al posto di “token” (es. “Io faccio le mie elaborazioni, poi passo il sasicchioneal dispositivodi firma che ne fa l’hash…”).