IT Design, Architetture e...

Social CRM - Concept, Benefits and Approach to adopt

2009-11-19T12:18:00.003+01:00

Il Social CRM è il primo vero step di applicazione concreta del Web 2.0 ...abbatte i costi e rende efficaci le interazioni clienti-aziende, oppure cittadini-amministrazione pubblica (Dion Hinchcliffe: Using social software to reinvent the customer relationship).

Social CRM - Concept, Benefits and Approach to adopt

View more presentations from Fabio Cipriani.

Internet advertising appears to begin its comeback

2009-10-21T21:55:00.021+02:00

Oct 20, 2009 8:25 PM By MICHAEL LIEDTKE, AP

After bogging down in the recession, Internet advertising is regaining the momentum that has made it the decade's most disruptive marketing machine. The signs of an online revival are emerging even while advertising in print and broadcasts remain in a slump that has triggered mass layoffs, pay cuts and other upheaval.

Internet advertising was just about the only bright spot in the third-quarter reports of two major newspaper publishers, Gannett Co. and McClatchy Co. Meanwhile the companies still are dealing with steep declines in print ads - an imbalance most analysts predict will take years to address. The harsh reality is that much of the advertising in long-established media, particularly in the classified sections of newspapers, will never rebound to pre-recession levels, said Lauren Rich Fine, a longtime media analyst who is now a professor at Kent State University.

That grim outlook contrasts with the fact that advertisers are increasingly allocating more of their budgets to the Web. That's where their customers are spending more of their free time. On top of that, Internet ad rates are less expensive, and the returns on online ad investments are easier to quantify. Even when they buy time in other media, advertisers are realizing they need to be promoting their wares on the Internet too.

"You can draw a straight line from the time when people hear an ad on the radio or television to when they search for that company on the Internet," said David Karnstedt, chief executive of Efficient Frontier, which helps manage ad campaigns on search engines. These trends will give Internet advertising 19 percent, or nearly $87 billion, of the worldwide ad market in 2013, up from just 4 percent, or about $18 billion, in 2004, according to PricewaterhouseCoopers and Wilkofsky Gruen Associates.

That would make the Internet the third-largest marketing medium. Television is expected to remain on top, with $168 billion, or 36 percent of the global ad market in 2013, up from 35 percent in 2004. Newspapers would still be No. 2, but their $92 billion in advertising revenue is projected to account for 20 percent of the global ad market, down from 28 percent in 2004. For now, though, some types of Internet advertising - real estate, travel and help-wanted, in particular - remain in the funk they fell into in the first half of the year, when U.S. ad revenue on the Web fell 5 percent. (That was still far better than the 12 percent to 29 percent declines suffered by U.S. newspapers, radio stations and television broadcasters.)

David Hallerman, a senior analyst at eMarketer, thinks it's too early to conclude the entire Internet advertising market is on the upswing. "It's more like the patient had a 105-degree temperature and now it's down to 100 degrees," he said. EMarketer expects Internet ad sales in the U.S. to fall by nearly 3 percent in the second half of this year, slightly less than in the first half. The research firm expects a 6 percent increase next year followed by a 7 percent gain in 2011. The most compelling evidence for an online recovery is being made by Google Inc., whose search engine powers an online network that has grown from $411 million in worldwide ad revenue in 2002 to more than $22 billion annually now. The company's ad revenue rose 7 percent in the third quarter, the fastest pace so far this year, and Google's executives indicated they are gearing up for even more rapid growth in the months ahead.

Google could be an anomaly because its specialty - selling ads tied to online search requests - tends to be the last thing cut from marketing budgets and the first thing to attract more money in the early stages of a recovery. The reason: Search requests have proven to be a highly effective way to identify consumers shopping for a specific product or service. And the ads typically cost advertisers only when the links are clicked on.

For instance, a Google ad tied to a search request containing the word "shoes" currently costs about $6.80 per click, while an ad generated by a request with the term "car parts" costs just 48 cents per click. Buying ads in major newspapers or on TV can easily cost thousands of dollars with no assurance the investment will deliver customers.

Besides the Internet's lower prices, the Web's tracking technologies make it easy to measure whether a search ad campaign is yielding adequate sales to justify the expense. If their online spending isn't paying off, advertisers typically can pull the plug more quickly than in print and broadcast, which often require financial commitments that last several months.

The greater flexibility online makes it easier to gauge the mood of consumers by buying Internet search ads before ramping up spending in other areas, Fine said. "I think a lot of (advertisers) are experimenting right now, hoping they can stimulate a little more demand," she said. "Some of this could be wishful thinking."

It might take longer to see an ad rebound at Yahoo Inc., which runs the Internet's second-most widely used search engine. Yahoo's forte is "display advertising" - online billboards and other more visual forms of marketing. Companies still seem reluctant to spend on those more elaborate campaigns, partly because they tend to be more expensive and not as well-aimed as search ads. The reticence is the main reason Yahoo reported its third-consecutive quarterly decline in ad sales Tuesday. Yahoo's ad revenue fell 12 percent after declining 13 percent in the first half of the year.

Even so, Yahoo isn't being hit as badly as newspaper publishers; McClatchy's print advertising, for instance, plunged 32 percent in the third quarter. Its online ad sales, on the other hand, increased 3 percent.

Search Engine Web versus Social Network Web

2009-09-03T12:54:00.006+02:00

Dal protocollo ip all'individuo - Da http://www.denaro.it/

Il web si va configurando come un sistema di relazioni slegato dai numeri - Carmine De Falco e Tonino Ferro

Mark Zuckerberg, alias "mister Facebook", rilascia questo mese al giornalista Fred Volgestein, per Wired, un'intervista che ha il potere di schiudere gli occhi sul futuro di internet.

"Apertura", è la parola chiave del pensiero del numero uno di Facebook. E (letteralmente) "terra a terra", il tipo di approccio con il quale confrontarsi nella nuova arena globale: è finita l'era dei mediatori e lo sviluppo del social network più famoso al mondo, dichiara Zuckerberg, va nella direzione dell'utente che condivide, che crea rapporti, a partire da un solo account, con un numero potenzialmente illimitato di persone.

La chiave della questione sembra questa: come migliorare le possibilità di connessione dell'utente. Per fare in modo che valga l'equazione: più persone connesse uguale più contenuti condivisi. Attenzione su questo punto in apparenza banale, perché scardina ogni rapporto utilitaristico e filosofico tra utente e contenuto stesso.

L'esperienza di Facebook dimostra, dice Zuckerberg, che "il numero di informazioni che la gente sta condividendo proprio ora cresce molto più velocemente del volume di blog e siti 'aperti' del web". Leggi: i siti e i blog sono gestiti da persone che filtrano informazioni; non ci son un produttore dell'informazione e un consumatore interessato.

Rimane in mezzo il blogger o il giornalista. I numeri spiegano meglio delle parole, e tolgono i lettori dall'imbarazzo del dubbio: su Facebook si caricano un miliardo di foto al mese e ci sono un miliardo di contenuti condivisi a settimana. Quale contenitore di conenuti può competere? Silenzio.Le dichiarazioni del sorridente ragazzone americano e le contromosse del gigante Google unite al desiderio di Microsoft di colmare il gap sul mercato dei motori di ricerca e dei servizi web, fanno pensare ad un'imminente guerra tra due mondi contrapposti:

- web "social network oriented"
- web "search engine oriented"

Già dalle parole si coglie la grande differenza, da un lato c'è la rete e il sociale, dall'altro un motore che rimanda alla meccanica. Sono diversi i fattori che spingono verso la nuova era, dal motore/algoritmo all'uomo/relazione, dalla dimensione logico-matematica alla dimensione semantica, dalla "scrivania" al mobile.

Il primo passaggio presuppone una navigazione non più anonima o associata ad un i.p. numerico, ma l'ingresso in rete di un individuo tramite piattaforme di gestione "universale", ovvero una sorta di "meta-social network" capace di organizzare da un unico account più profili di uno stesso utente (vedi friend feed).

Il secondo passaggio, la vera rivoluzione del web che verrà, permetterà, riconosciuta l'identità dell'utente, di proporre sullo spazio virtuale del web, una serie di contenuti, audio, video, informativi, elaborati sulla base delle attività e degli interessi reali, e non su algoritmi logico-matematici.

Il terzo passaggio, riguarda l'affermazione dell'internet mobile, ovvero la possibilità di navigare e di essere così costantemente connessi dal proprio cellulare (sempre più ricco di funzioni, rapido, e interattivo).

In sintesi, il web sarà personale, portatile, condiviso, relazionale e potenzialmente sempre "on".

Facile immaginare come tutto ciò comporterà un'ennesima e ulteriore rivoluzione cognitiva, che stravolgerà completamente l'attuale scenario dei media.

Continuous Integration as solution in Economic Meltdown?

2009-07-26T22:41:00.009+02:00

Ognuno ha la sua vision ma la costante di questa fase economica è che quasi tutte le aree tecniche IT sono focalizzate... sui budget disponibili!!!
Budget che sono oggi, ancor di più che nel passato, il vero driver di ciò che è possibile fare o non fare…
“In economic meltdown CFO is a CIO!!!” e mai come adesso, in qualsiasi realtà, forse questo è vero!!!
L'economic meltdown probabilmente sarà la tomba di ciò che si è già rivelato inefficace nel corso degli ultimi anni ... Le rigide modalità organizzative dipartimentali (anni ‘80) che “generano” solo conflitti di competenze (e questo lo sapevamo già bene!)... spazzate via quindi...
Ma spazzato via ugualmente anche il modello (anni 2000) su cui si erano riposte invece molte speranze di Creative Software Factory ….
Modello, quest’ultimo, che ha mostrato la corda purtroppo per profitti troppo bassi o inesistenti ...rispetto ai costi di un sostanziale R&D in continuum…
Qualcosa del genere fanno gli americani ma loro hanno l'esperienza consolidata dei Venture Capitalist... un "concreto" R&D che in Europa ammettiamolo ... nessuno sa veramente fare... nè il Pubblico nè il Privato...
Purtroppo altri modelli consolidati al momento non sono in vista, li stanno cercando tutti del resto.
L’unica cosa che forse si può fare, secondo le best practices raccomandate, almeno per le aree di competenza tecnica, è di avvicinarsi il più possibile alle esigenze di:

a) Time to market
b) Business Continuity

In sostanza velocità di implementazione e stabilità di piattaforma.
Gli unici modelli architetturali compatibili per gestire entrambe queste esigenze sono forse quelli della Continuous Integration & Perpetual Beta ... Anche perchè consentono di comprimere, (perchè gestiti in modalità automatica!!!) i costi di ruoli diversificati (tester, operation, management, software developer).

Sono modelli verso cui ogni giorno converrebbe ruotare pian piano le piattaforme ed infrastrutture software.

Sulle discipline di project management anche lì c’è profonda evoluzione in corso ed il profilo di PM&Manager tradizionale, mero pusher & dispatcher di attività, sta mostrando definitivamente la corda anch’egli…
Anzi si sta sempre di più facendo strada il modello di riferimento di PM&Manager a forte valenza tecnica … con competenze di business ed attenzione ai costi, ai profitti ed ai budget….
Sono questi PM quelli ideali per essere connector tra le aree tecniche e di business e sono questi profili i veri catalizzatori di attività e fatturati per le aziende.
Con questi profili difficilmente sorgono problemi di efficienza ed efficacia delle strutture … perché si tratta di Manager che hanno già dimostrato sul campo, ed a tutti i team coinvolti, di essere tecnici ed esperti di business allo stesso tempo…

Do you wanna be an Architect when you grow up?

2009-07-14T18:52:00.002+02:00

From - Is Design Dead?
Martin Fowler Chief Scientist, ThoughtWorks

Do you wanna be an Architect when you grow up?
For much of the last decade, the term "software architect" has become popular. It's a term that is difficult personally for me to use. My wife is a structural engineer. The relationship between engineers and architects is ... interesting. My favorite was "architects are good for the three B's: bulbs, bushes, birds". The notion is that architects come up with all these pretty drawings, but it's the engineers who have to ensure that they actually can stand up. As a result I've avoided the term software architect, after all if my own wife can't treat me with professional respect what chance do I stand with anyone else?
In software, the term architect means many things. (In software any term means many things.) In general, however it conveys a certain gravitas, as in "I'm not just a mere programmer - I'm an architect". This may translate into "I'm an architect now - I'm too important to do any programming". The question then becomes one of whether separating yourself from the mundane programming effort is something you should do when you want to exercise technical leadership.
This question generates an enormous amount of emotion. I've seen people get very angry at the thought that they don't have a role any more as architects. "There is no place in XP for experienced architects" is often the cry I hear.
Much as in the role of design itself, I don't think it's the case that XP does not value experience or good design skills. Indeed many of the proponents of XP - Kent Beck, Bob Martin, and of course Ward Cunningham - are those from whom I have learned much about what design is about. However it does mean that their role changes from what a lot of people see as a role of technical leadership.
As an example, I'll cite one of our technical leaders at ThoughtWorks: Dave Rice. Dave has been through a few life-cycles and has assumed the unofficial mantle of technical lead on a fifty person project. His role as leader means spending a lot of time with all the programmers. He'll work with a programmer when they need help, he looks around to see who needs help. A significant sign is where he sits. As a long term ThoughtWorker, he could pretty well have any office he liked. He shared one for a while with Cara, the release manager. However in the last few months he moved out into the open bays where the programmers work (using the open "war room" style that XP favors.) This is important to him because this way he sees what's going on, and is available to lend a hand wherever it's needed.
Those who know XP will realize that I'm describing the explicit XP role of Coach. Indeed one of the several games with words that XP makes is that it calls the leading technical figure the "Coach". The meaning is clear: in XP technical leadership is shown by teaching the programmers and helping them make decisions. It's one that requires good people skills as well as good technical skills. Jack Bolles at XP 2000 commented that there is little room now for the lone master.
Collaboration and teaching are keys to success.

Continuous Integration is an Attitude

2009-07-14T18:09:00.005+02:00

From http://jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html
by James Shore - 18 Aug, 2005

Contrary to popular belief, continuous integration is an attitude, not a tool. It's a shared agreement by the team that:

- When we get the latest code from the repository, it will always build successfully and pass all tests.
-We will check in our code every two to four hours.

There's lots of ways to make this happen, but they tend to be a variation on this theme:

- Before check-in, run the build and tests and make sure they pass.
- Tell people not to update from the repository because you're doing an integration.
- Check in.
- Go to a different machine (often a dedicated "integration machine"), get the latest code from the repository, and make sure latest changes build and pass there, too.
- Done--tell people they can update again.

The purpose of step indicated as "Go to a different machine" is to make sure that the code will work on everybody's machine, not just the machine of the guy who wrote the code. You tell people not to update just in case it doesn't work. If it doesn't, you have to fix it or roll back your changes. Either way, people won't ever have a problem with getting code that doesn't work ...

Product Development Philosophy - Micheal Cusumano, Synchronize-and-Stabilize e dintorni ...

2009-05-20T17:39:00.007+02:00

Tratto da Microsoft Secret's - Michael Cusumano

http://www.amazon.com/Microsoft-Secrets-Powerful-Software-Technology/dp/0684855313

Product Development Philosophy: How to coordinate the work of a large team building many interdependent components that are continually changing requires a constant and high level of communication and coordination.

It is difficult to ensure that this communication and coordination take place while still allowing designers, engineers, and marketing people the freedom to be creative. Achieving this balance is perhaps the central dilemma that managers of product development face -- in Microsoft as well as in companies from many other industries.

Dave Maritz, a former tank commander in the Israeli army who headed the MS-DOS/Windows testing group, commented on how he and other Microsoft managers try to impose only enough direction and iron-clad rules so that individuals and teams can work together toward the common goal of getting a new product out the door:

"In the military, when I was in tank warfare and I was actually fighting in tanks, there was nothing more soothing than people constantly hearing their commander's voice come across the airwaves. Somebody's in charge, even though all shit is breaking loose.... When you don't hear [the commander's voice] for more than fifteen minutes to half an hour, what's happened? Has he been shot? Has he gone out of control? Does he know what's going on? You worry.

And this is what Microsoft is.

These little offices, hidden away with the doors closed. And unless you have this constant voice of authority going across the e-mail the whole time, it doesn't work.

Everything that I do here I learned in the military....

You can't do anything that's complex unless you have structure.. .

And what you have to do is make that structure as unseen as possible and build up this image for all these prima donnas to think that they can do what they like.

Who cares if a guy walks around without shoes all day? Who cares if the guy has got his teddy bear in his office? I don't care.

I just want to know ... [if] somebody hasn't checked in his code by five o'clock. Then that guy knows that I am going to get into his office."

RSS Feed questi sconosciuti...

2009-05-09T19:20:00.010+02:00

Sempre più spesso ci capita di spiegare cosa siano i feed RSS e quali siano le potenzialità di questo strumento semplicissimo.
Strumento che consente sia di esporre i propri contenuti sul web sia di leggerli separati dal loro contesto di pubblicazione.

Vi è su YouTube un video (di cui esiste anche una versione italiana) efficacissimo e molto chiaro su come gli RSS stiano rivoluzionando la modalità di fruizione dei contenuti sul web.

Il navigatore online sta passando infatti da una modalità sostanzialmente passiva (user che si indirizza verso le news) ad una invece attiva (sono le news/contenuti, e solo quelli selezionati, che viaggiano verso lo user).

Lo schema seguente da un'idea di come agiscono gli RSS.

Il web quindi sta modificando rapidamente il rapporto di forza esistente tra chi produce i contenuti (e ne detiene la possibilità di accesso e distribuzione) ed il lettore.

Lettore che, ormai, non è più solo soggetto passivo ma è egli stesso parte attiva del processo di selezione e creazione dei contenuti.

E gli RSS sono gli apriscatole a bassisimo impatto sufficienti per questo sostanziale cambio di paradigma in corso...

Ecco il link http://www.youtube.com/watch?v=8FmePY7dwDg

Web 2.0...The Machine is Us

2009-03-08T10:57:00.004+01:00

Questo video è considerato il Manifesto del Web 2.0

E' un video di Michael Wesh, docente di Antropologia Culturale alla Kansas State University, che racconta in meno di 5 minuti la rivoluzione in corso.

Sopravviveranno e saranno on the edge della tecnologia solo le imprese e le comunità che avranno saputo adattarsi al nuovo modo di comunicare e costruire relazioni di carattere affettivo, commerciale, politico e culturale.

Use of SOA and Web Services Technologies for EA Migration

2009-03-07T22:32:00.005+01:00

SlideShare Presentation del 2007 ma sempre attuale.
Importantissima la Web Service Classifications.
Spesso nel corso della definizione delle specifiche architetturali si ascolta da alcuni membri del team la famigerata frase "facciamolo con un web services"!
Se quel web services non rientra in alcuna tipologia classificata forse si sta decidendo di utilizzare lo strumento sbagliato!!!

Use of SOA and Web Services Technologies for EA Migration - Lessons Learned on How to Sort it All Out

View more presentations from Nathaniel Palmer. (tags: soa web)

The Power Of Refactoring

2009-03-07T21:38:00.005+01:00

SlideShare Presentation sull'argomento del code refactoring e su come esso sia basato su principi e metodi che lo rendono assai diverso da una semplice operazione di riscrittura del codice.

Rifattorizzare il codice è peraltro attività da considerarsi ormai ordinaria e prassi quotidiana, soprattutto in ambito di Web Technologies dove la modalità operativa è sempre più perpetual beta.

The Power Of Refactoring (4developers Krakow)

View more presentations from Stefan Koopmanschap. (tags: design software)

Sequoia Capital on startups and the economic downturn

2009-03-07T21:26:00.005+01:00

SlideShare Presentation di analisi sull'attuale congiuntura economica per uno dei principali Venture Capitalist statunitensi in ambito tecnoologico, Sequoia Capital.
Vi sono indicazioni e linee guida su come gestire oggi gli investimenti in ambito tecnologico e su come ed in quali specifici settori tali investimenti siano condizionati fortemente dall'attuale congiuntura.

Sequoia Capital on startups and the economic downturn

View more presentations from Eric Eldon. (tags: depression recession)

Chris Peters: Microsoft Office Architect, Synchronize and Stabilize!

2009-02-10T21:54:00.009+01:00

Vi è da anni nel settore delle metodologie relative allo sviluppo software un gran parlare e discutere su quale sia il processo più efficace o più adatto …
Nell’ambito delle tecnologie web (che sono oramai le tecnologie di punta per tutte le software farm, o quanto meno quelle su cui vi è maggior aspettativa) ormai si è di fatto affermato il concetto di perpetual beta (beta perenne)… il software cioè si evolve così velocemente e così agganciato al business da non consentire di arrivare ad una versione stabile del prodotto. Il paradosso è che la versione Online del software web, pur essendo sempre in versione beta, ha un suo livello di stabilità intrinseca dato anche dalla capacità e dall’abitudine mentale dei developer che lo evolvono e lo mantengono in esercizio di aggiornare progressivamente e fixare i bug e le nuove funzionalità con continuità… Essi sincronizzano e stabilizzano il software praticamente ogni giorno…
In effetti, e pochi lo sottolineano, tale metodologia di prassi oramai nell’ambito web (vedi Google e la sua consolidata filosofia di always in beta version) ha un suo precursore nel lavoro e nella teorizzazione realizzata in Microsoft a partire dalle prime versioni di Windows (anni '80) mediante un processo definito come Synchronize-and-Stabilize.

Synchronize-and-Stabilize è un processo di sviluppo software assai efficace ed orientato principalmente alla realizzazione del prodotto… come dicono gli americani focalizzato fortemente quindi unicamente to ship products.
Ecco di seguito le parole, che descrivono con efficacia tale filosofia di sviluppo software, di Chris Peters, l’Architetto Microsoft che guidò il team che integrò, in modalità Synchronize-and-Stabilize, le prime versioni di Microsoft Office :

“Everybody in a business unit has exactly the same job description and that is to ship products. Your job is not to write code. Your job is not to test. Your job is not to write specs.

Your job is only to ship products....

When you wake up in the morning and you come to work, you say what is the focus? Are we trying to ship? Are we trying to write code? The answer is we are trying to ship.... You're trying not to write code.

If we could make all this money by not writing code, we'd do it.”

Gartner costs cutting: 25 ways to cut IT costs

2009-02-07T10:12:00.015+01:00

Gli IT Architect sono figure intermedie che indirizzano le scelte tecniche dei team IT anche e soprattutto in virtù di una loro valenza economica… e quindi devono tener conto dell’economic meltdown in atto ed agire di conseguenza.
E come adesso dicono gli anglosassoni con una battuta… questi son tempi in cui i Chief Financial Officer divengono i veri CIO!!!

Gartner ha di recente emesso una sorta di vademecum operativo (25 suggerimenti) su come operare un efficace controllo dei costi attraverso i quattro versanti trasversali dell’IT:

- IT management
- enterprise software
- enterprise infrastructure and operations (networks and telecom)
- enterprise infrastructure (hardware & IT operations)

Eccoli di seguito:

Cut costs through more effective IT management methods

-Focus initially on cutting "people costs": Freeze headcount, reduce/eliminate special bonuses, reduce regional support.
-Flatten organization structure: Move to collaborative, team-based models.
-Accelerate the progress of centralized and shared services: Leverage enterprise-wide competencies, reduce staff embedded in business units.
-Bring a qualified finance person into your IT leadership team, perhaps on loan or on temporary contract.
-Maintain or strengthen relationship management roles: Business analysts, business process and industry experts, account executives, relationship managers.
-Take control of "unmanaged" costs you can measure and cut easily, such as data center power consumption or printing.

Cut costs in enterprise software (Caution ahead!)

-Use invoice verification.
-Eliminate unused software/modules. Understand who's using what and why. Lots of closet cleaning here.
-Apply more sophisticated negotiations."You can't put someone who bought pencils into a negotiation" with a big software vendor, Gartner's Bill Snyder said. "They'll get eaten alive."
-Use alternative products included in previous deals.
-Introduce competition for existing products. You must foster vendor competition if you hope to lower costs. If you decide to switch, make sure you calculate the cost of taking out the incumbent beforehand.
-Use "best-for-need" rather than "best-of-breed" products. You could be paying as much as a 50% premium for best of breed, Snyder said.

Cut costs in enterprise infrastructure and operations: Networks and telecom

-Use telecom expense management services (save 10% to 35%). Nobody can keep track of this stuff. Hire a professional to source, benchmark, negotiate the contracts, etc., and audit the bills.
-Move to corporate liability for wireless services (save 15% to 30%). Who's responsible for the bills of individuals, what devices they use? The enterprise should take control and set standards, Gartner analyst Phil Redman said.
-Reduce the reliability target for a location by "one 9" (save 30%).
-Collapse rich media conferencing into a premises-based multi-control point unit (save 60%). As hardware costs come down, building your own videoconferencing center can save big money over the long run, assuming you do a lot of it.
-Deploy IP telephony and Voice over Internet Protocol (save 50% to 80% of maintenance).
-Use the Internet as corporate transport (save 10% to 80%).

Cut costs in enterprise infrastructure, hardware and IT operations

-Defer 2008 Windows XP PC replacements to 2009. Three-year-old PCs and 2-year-old laptops might be able to go another year, but you should be mindful of the maintenance costs, Gartner analyst Michael Silver said.
-Exploit commoditization: the best-for-need instead of best-of-breed argument, redux.
-Make better use of existing tools by improving process and policy.
-Defer client architecture pilot/evaluation projects.
-Implement thin provisioning and data de-duplication for storage reduction.
-Consolidate and virtualize servers.

Emerging trends in IT cost pressure
Target two or three areas for "zero-based budgeting" in 2009.
Start the process soon Gartner said: "Current-year cost-saving opportunities will be revealed."

Best Practices: Thinking in C++ di Bruce Eckel

2009-01-29T20:59:00.016+01:00

Tra le letture che consigliamo vi è Thinking in C++ di Bruce Eckel. La prima edizione è del 2000 ma i concetti espressi sono ancor oggi molto moderni. Vi sono elencate una serie di best practices fondamentali per chi scrive codice e ciò indipendentemente dalla piattaforma tecnologica utilizzata.
Di seguito una serie di spunti di riflessione tratti e tradotti (molto!) liberamente dal testo originale... e per non prenderci troppo sul serio lasceremo la parola a Dilbert, mitico personaggio di Scott Adams che tutti i developer per la loro sopravvivenza tecnica e non solo (altra lettura consigliata è The Career Programmer: Guerilla Tactics for an Imperfect World) dovrebbero tener in gran conto... forse ancor più di Bruce Eckel!!!

1. Prima fatelo funzionare, poi rendetelo veloce! Questo è vero anche se siete certi che un qualsiasi frammento di codice sia realmente importante e che diverrà esso il collo di bottiglia principale del vostro sistema. Non toccate quel frammento per ottimizzarlo. Prima di tutto cercate di ottenere un sistema funzionante con un progetto il più semplice possibile. Soltanto dopo, se non è abbastanza veloce, lo analizzerete. Quasi sempre scoprirete che il vero problema non è il "vostro" collo di bottiglia. Risparmiate tempo per le cose veramente utili.

2. L'eleganza nella scrittura del codice paga sempre. Non è un'attività frivola. Avrete in mano un programma non solo più facile da compilare e testare, ma anche più semplice da comprendere e da manutenere: ed è qui che si ritrova il valore economico del vostro lavoro. Potrebbe servire un po' di esperienza prima di comprendere questo dato, in quanto potrebbe apparire che, mentre cercate di rendere elegante un frammento di codice, non siete in realtà produttivi. La produttività emergerà poi quando il codice si integrerà perfettamente nel vostro sistema, ed ancor più quando il codice o il sistema verrà modificato.

3. Ricordatevi del principio "divide et impera". Se il problema che state affrontando è troppo complesso, cercate di immaginare quali potrebbero essere le operazioni basilari del programma. Magari immaginando un "qualcosa" che si occupi delle parti più difficili!
Questo qualcosa è un oggetto e quindi scrivete il codice che utilizza quell'oggetto. Successivamente analizzate l'oggetto ed incapsulate le sue parti complicate all'interno di altri oggetti, e così via.

4. Se avete un grosso blocco di codice che ha bisogno di modifiche, cominciate ad isolarne le parti che non verranno modificate, eventualmente inglobandole in una"classe API" come metodi statici. Successivamente, focalizzate la vostra attenzione sul codice che verrà modificato, ristrutturandolo in classi. In tal modo renderete agevoli le modifiche man mano che la vostra attività di manutenzione procederà.

5. Tenete ben distinti il creatore della classe dal suo utilizzatore (il programmatore client). Chi utilizza la classe è il "cliente", e non ha bisogno né vuole sapere cosa accade dietro le quinte. Chi crea la classe dev'essere l'esperto di progettazione di classi e deve scriverla in modo che possa essere usata anche dal più principiante dei programmatori, continuando a comportarsi in maniera robusta nell'applicazione. L'utilizzo di una qualsiasi libreria è semplice soltanto se è trasparente.

6. Quando create una classe, usate una nomenclatura il più chiara possibile. Il vostro obiettivo è quello di rendere l'interfaccia di programmazione concettualmente semplice. Cercate di rendere i vostri nomi talmente chiari da rendere superflui i commenti. A tal fine, sfruttate l'overloading delle funzioni e gli argomenti di default per creare un'interfaccia intuitiva e facile da usare.

7. Il controllo dell'accesso consente a voi (creatori della classe) di fare in futuro estese modifiche che saranno quindi possibili senza danneggiare il codice client nel quale la classe è utilizzata. In questa prospettiva, mantenete tutto il più private possibile, e rendete public solo l'interfaccia della classe, utilizzando sempre le funzioni anziché i dati. Rendete i dati public solo quando siete costretti. Se gli utilizzatori di una classe non hanno bisogno di richiamare una funzione, dichiaratela private. Se una parte della vostra classe deve restare visibile alle classi eventualmente ereditate come protected, fornite un'interfaccia a funzioni piuttosto che esporre direttamente i dati. In questo modo, le modifiche di implementazione avranno un impatto minimo sulle classi derivate.

8. Prima di tutto e se possibile scrivete il codice di test. Ancor prima di scrivere la classe e poi tenetelo in evoluzione insieme alla classe. Rendete automatica l'esecuzione dei vostri test magari tramite un makefile oppure mediante uno strumento similare. In questo modo, qualunque modifica potrà essere controllata automaticamente lanciando il codice di test, e gli errori verranno immediatamente scoperti. Sapendo di avere la rete di sicurezza dell'ambiente di test, sarete più propensi ad effettuare modifiche consistenti quando ne sentirete il bisogno. Ricordate che i maggiori miglioramenti nei linguaggi di programmazione vengono dai controlli interni forniti da controllo del tipo, gestione delle eccezioni e così via, ma queste caratteristiche servono fino ad un certo punto. Dovete arrivare in fondo alla strada che porta alla creazione di sistemi robusti introducendo i test che verificano le caratteristiche specifiche della vostra classe o del vostro programma.

9. Ricordate una regola fondamentale dell'Ingegneria del Software: tutti i problemi di progetto del software possono essere semplificati introducendo un ulteriore livello di dereferenziamento concettuale. Quest'idea sta alla base dell'astrazione, la caratteristica primaria della programmazione orientata agli oggetti.

10. Rendete le classi le più atomiche possibile; in altri termini, date ad ogni classe un unico scopo chiaro. Se le vostre classi o il vostro progetto del sistema diventano troppo complicati, suddividete le classi complesse in classi più semplici. Il segnale più ovvio di questo fatto è proprio la stessa dimensione: se una classe è grande, c'è la possibilità che stia facendo troppo e che quindi è necessario scomporla.

11. Guardatevi dalle definizioni dei metodi lunghe. Una funzione lunga e complicata è difficile e costosa da mantenere, e probabilmente sta cercando di fare troppo da sola. Se vi trovate a maneggiare una funzione del genere, significa che, quanto meno, andrebbe suddivisa in alcune funzioni più piccole. Potrebbe anche suggerire la creazione di una nuova classe.

12. Guardatevi dalle liste di argomenti lunghe. Le chiamate di funzione diventano difficili da scrivere, leggere e manutenere. Piuttosto, cercate di spostare il metodo in una classe nella quale sia più adatto, e/o a passargli un oggetto come parametro.

13. Non ripetetevi. Se un pezzo di codice compare in molte funzioni nelle classi derivate, spostate quel codice in un'unica funzione nella classe base e chiamatelo dalle funzioni delle classi derivate. Non solo risparmierete spazio, ma consentirete un'agevole propagazione delle modifiche. Potete utilizzare una funzione inline perl'efficienza. Talvolta, la scoperta di questo codice comune porta considerevoli benefici alla funzionalità della vostra interfaccia.

14. Guardatevi dalle istruzioni switch o dagli if-else concatenati. Tipicamente, questo è un chiaro indicatore della programmazione di tipo type-check.
Programmazione type - check significa che state scegliendo quale codice eseguire in base ad un qualche genere di informazione sul tipo (il tipo esatto potrebbe non esservi immediatamente chiaro). Solitamente, potete rimpiazzare questo genere di codice sfruttando ereditarietà e polimorfismo; la chiamata ad una funzione polimorfica eseguirà il controllo di tipo per voi, e consentirà un estensibilità più affidabile e semplice. [N.d.T. - In realtà il controllo sui tipi è caratteristico del C++ che è un linguaggio fortemente tipizzato, ma il principio è comunque valido come punto di attenzione di ordine generale, nel senso che un eccesso di if-else nidificati è sicuramente indice di entropia elevata che state inserendo nel codice.]

15. Guardatevi dalle limitazioni nell'ereditarietà. I progetti più puliti aggiungono nuove funzionalità a quelle ereditate. Diffidate di un progetto che rimuove le vecchie funzionalità (mentre state ereditando) senza aggiungerne altre. Ma le regole sono fatte per essere infrante, e se state lavorando con una vecchia libreria di classi potrebbe essere più efficiente restringere una classe esistente nelle sue sottoclassi, piuttosto che ristrutturare la gerarchia in modo che la vostra nuova classe si vada ad inserire dove dovrebbe, al di sopra della vecchia classe.

16. Non estendete le funzionalità fondamentali nelle sottoclassi. Se un elemento dell'interfaccia è fondamentale per una classe si dovrebbe trovare nella classe base, e non essere aggiunto nel corso delle derivazioni. Se state aggiungendo dei metodi tramite l'ereditarietà, forse dovreste ripensare il progetto.

17. Meno è più. Iniziate da un'interfaccia minimale per la classe, semplice e piccola quanto basta per risolvere il vostro problema corrente, ma non cercate di anticipare tutti i modi nei quali la vostra classe potrebbe essere usata. Al momento del suo utilizzo, scoprirete il modo nel quale dovrete espandere l'interfaccia. Comunque, una volta che la classe è in uso, non potete modificarne l'interfaccia senza disturbare il codice client. Se avete bisogno di aggiungere più funzioni, va bene; non creerà problemi al codice, se non la necessità di una ricompilazione. Ma anche se i nuovi metodi rimpiazzano le funzionalità di quelle vecchie, lasciate da sola l'interfaccia già esistente (se volete, potete combinare le funzionalità nell'implementazione sottostante). Se avete bisogno di espandere l'interfaccia di una funzione esistente aggiungendo nuovi argomenti, lasciate gli argomenti già esistenti nel loro ordine, ed assegnate dei valori di default a tutti quelli nuovi; in questo modo, non creerete problemi a nessuna chiamata già esistente a quella funzione.

18. L'overloading degli operatori è soltanto "zucchero sintattico": un modo diverso per chiamare una funzione. Se l'overloading di un operatore non rende l'interfaccia della classe più chiara e semplice da usare, non fatelo. Per una classe create solo un operatore per la conversione automatica di tipo.

19. Non preoccupatevi di un'ottimizzazione prematura. È pura follia. In particolare, non preoccupatevi di forzare il codice ad essere efficiente quando state appena costruendo il sistema. Il vostro scopo principale è di verificare il progetto, a meno che lo stesso richieda una certa efficienza.

20. Mantenete gli scope più piccoli possibile, in modo che la visibilità e la vita dei vostri oggetti siano le più ridotte possibile. In questo modo, si diminuisce la possibilità di utilizzare un oggetto in un contesto sbagliato e di nascondere un bug difficile da trovare.

21. Evitate, evitate, evitate il più possibile... non ci stancheremo mai di ribadirlo, le variabili globali. Cercate sempre di inserire i dati all'interno delle classi. È più probabile imbattersi in funzioni globali piuttosto che in variabili globali, sebbene potreste rendervi conto in seguito che una funzione globale troverebbe una collocazione più consona come metodo static di una classe.

22. Sfruttate a vostro vantaggio il controllo degli errori effettuato dal compilatore. Compilate il vostro codice abilitando tutti i warning, e correggete il vostro codice inmodo da eliminarli tutti. Scrivete codice che utilizza gli errori ed i warning al momento della compilazione, piuttosto che codice che provochi errori di runtime. Utilizzate assert per il debug, ma a runtime usate le eccezioni.

23. Preferite gli errori di compilazione agli errori di runtime. Cercate di gestire un errore il più vicino possibile al punto in cui si è verificato. È preferibile gestire l’errore in quel punto piuttosto che lanciare un eccezione. Catturate le eccezioni nel gestore più vicino che abbia informazioni sufficienti per gestirle. Fate il possibile con l’eccezione al livello corrente; se in questo modo non risolvete il problema, rilanciatela nuovamente.

24. Non create una vostra notazione “personalizzata” per i nomi delle variabili membro (underscore, prefissi, variazioni fantasiose della notazione ungherese e così via), a meno che non abbiate una gran quantità di variabili globali preesistenti; se così non è, lasciate che le classi ed i namespace svolgano il lavoro per voi.

Architects: John Von Neumann, l'Architetto Supremo

2009-01-27T23:31:00.010+01:00

E' difficile, molto difficile, scrivere di John Von Neumann... In realtà dovrebbe esserci tanto materiale in rete su questo mito dell'informatica da rendere pressochè inutile aggiungere nulla. E nulla di ulteriore...
Ci si immagina che, essendo John Von Neumann l'Architetto Supremo, colui che ha reso di fatto possibile tutto ciò che possiamo definire come "mondo digitale", Internet compresa, niente debba essere aggiunto.
Ed invece la Rete non omaggia per niente il suo Creatore ...
Vi è pochissimo materiale, per di più assai disorganico, per chiunque voglia approfondire l'argomento. Ma forse non è solo colpa della Rete in verità.
Ho un ricordo personale di quando ebbi uno dei miei primo incontro con il mondo della programmazione e dei calcolatori.
Università, corso di Programmazione dei Calcolatori Elettronici. Von Neumann fu solo una citazione, al volo ed assai superficiale in verità, da parte del professore di turno.
Un sintetico accenno al diagramma (capolavoro di astrazione e semplicità) sull'architettura della MAG (Macchina Astratta Generalizzata), qualche cenno storico sull'ENIAC (il primo elaboratore così come noi oggi lo intendiamo) e via, subito avanti con il corso di programmazione... Fortran 77 ed UNIVAC 1100 (schede perforate!) come elaboratore del Laboratorio di Informatica.
Si dice che Von Neumann disegnò lo schema della MAG in pochi minuti, dopo aver compreso immediatamente che i progettisti di ciò che divenne poi l'ENIAC brancolavano nel buio ... nel buio fitto dell'Assenza dell'Intuizione.

Oggi, quasi sempre, quando si parla di Von Neumann e del suo Supremo Eclettismo (è stato anche uno dei più grandi matematici dell'era moderna), non sono pochi, purtroppo, i professionisti del settore IT che frugano alla rinfusa nella propria memoria.

E stiamo parlando, quando parliamo di Von Neumann, di colui che postulò e rese possibile l'applicazione del bit come unità di misura elementare dell'informazione.

Von Neumann è stato, comunque, senz'altro un genio e come spesso accade per le personalità eccezionali, di certo anche un genio del male.

A lui dobbiamo, infatti, anche la prima sistematica e non disinteressata collaborazione della scienza con l'industria degli armamenti. Ciò tramite un'organizzazione, la Rand Corporation, di cui egli fu uno dei massimi esponenti ed anche, forse, azionista occulto.

Insieme al suo amico, il fisico nucleare Edward Teller, scomparso peraltro di recente, rappresentò l'altra faccia della scienza, quella che negli Stati Uniti proponeva ad ogni riunione strategica presso il Gabinetto Presidenziale, l'esigenza di garantirsi il "primo colpo" durante la cosiddetta Guerra Fredda. In piena aderenza ai principi della Teoria dei Giochi.

I loro avversari, di Teller e Von Neumann, erano i Fermi, gli Oppheneimer, Einstein ed il paradosso era che tutti loro insieme, gli avversari di Von Neumann, che dopo la fine della seconda guerra mondiale assunsero il ruolo di colombe pacifiste, in realtà avevano loro stessi contribuito in maniera decisiva alla creazione del Nucleare Militare.

Molto più dello stesso Von Neumann che vediamo in una foto storica qui di seguito insieme ad Oppheneimer ed all'ENIAC.

Fermi aveva dimostrato la possibilità della reazione atomica di fissione, e sapeva bene, quando replicò l'esperimento negli Stati Uniti, a cosa sarebbe servito.
Einstein aveva addirittura scritto una lettera di preghiera al presidente Roosvelt affinchè si dotasse il progetto Mahnattan dei finanziamenti necessari. Ed Einstein argomentava la richiesta motivandola con la terribile necessità di sconfiggere ad ogni costo il mostro nazista.
Per Von Neumann il mostro da sconfiggere a qualsiasi prezzo sarebbe stato quello comunista.

Oppenheimer, last but not the least, fu lo scienziato dotato di capacità organizzative eccezionali che rese possibile arrivare alla Bomba in pochissimi anni. Il responsabile operativo dell'organizzazione del Progetto Mahnattan. Uno dei pìù grandi Organizzatori della storia, forse in quel periodo secondo solo ad Albert Speer, il Ministro degli Armamenti di Hitler, un altro Architetto. Architeto di Organizzazioni.
Tutti colombe comunque, Einstein e quelli della sua cerchia, dopo il lancio della Bomba...

L'unico demone ufficiale per così dire, però, è rimasto Von Neumann ... dimenticato o meglio omesso. Conosciuto solo dagli specialisti del settore, dai matematici e del tutto ignoto ai più.
Il creatore della Teoria dei Giochi, altro caposaldo fondamentale tra innumerevoli discipline scientifiche, insieme a Nash ... ma questa è ancora un'altra storia...

Enterprise Web 2.0 Agenda del 2009 – Dion Hinchcliffe Predictions

2009-01-26T21:19:00.009+01:00

Il guru del Web 2.0, Dion Hinchcliffe, ha di recente pubblicato un abstract delle sue predizioni relative al 2009. Previsioni e trend attese da tutta la comunità mondiale dell'enterprise Web 2.0.
Ovvia premessa … anche Hinchcliffe prende atto della grave situazione economica mondiale, ma con lo spirito tipico degli americani (e l’elezione di Obama, interprete di un auspicato New Deal è significativa in tal senso) anche il guru indiscusso del Web 2.0 mondiale ritiene che, dal punto di vista dell’IT, si sia di fronte ad una singolare chance.

Chance è un termine che esiste sia nel vocabolario francese sia in quello anglosassone.

Per i francesi ha più il significato di destino, fato.

Per gli anglosassoni significa prevalentemente sfida, opportunità.

… e da come sta reagendo il Vecchio Continente alla crisi mondiale si comprende la netta differenza tra i Due Mondi …
L’Europa sta attendendo il suo destino in una sostanziale inazione, aspettando che, per così dire, passi la bufera…
L’America sta cercando invece attivamente la sua chanche, sfida…

Ed il Web 2.0, per gli statunitensi, rappresenta una delle opportunità più chiare, certe e definite in ambito di web technologies.

Opportunità peraltro estremamente pragmatica e concreta.
Lo schema precedente di Hinchcliffe è chiaro ed immediato.
Solo due note ci interessa quindi sottolineare del suo articolo (che può essere visionato integralmente al link http://blogs.zdnet.com/Hinchcliffe).

Le piattaforme di Social Network, secondo Hinchcliffe, conviene estenderle e dispiegarle soprattutto:

verso ed in integrazione con i sistemi CRM, che già hanno necessità vitale di espandere la qualità dell’interazione con i Clienti (gestire in sostanza quello che i Call Center non sono stati in grado di gestire in questi anni)

per la condivisione della conoscenza interna alle aziende (le piattaforme di collaborazione lavorano più efficacemente in modalità Wiki e su sistemi basati su criteri di social networking in integrazione e collaborazione con il mondo esterno – vedi caso del R&D della Procter & Gamble esternalizzato in modalità Wiki).

In questa ottica sono purtroppo assai sintomatici gli atteggiamenti di chiusura (blocco delle porte Internet, per i loro dipendenti, verso tutte le piattaforme Web 2.0 come Twitter, Facebook, You Tube, Instant Messanging come Microsoft Messenger…) che molte aziende europee stanno attuando in maniera sistematica nei confronti del Web 2.0 che dilaga ormai su Internet.

Dilagano e si espandono le piattaforme Web 2.0 e come tutte le novità tecnologiche fanno anche un po’ paura!!!

Vi è di certo un equivoco su cosa sia il Web 2.0 e di come siano acceleratori virali e catalizzatori di conoscenza (Internal Knowledge) le reti sociali e non si comprende quindi la chiusura anche dei mass media (vedi sempre le campagne aggressive di denigrazione di Facebook sui media tradizionali - stampa e televisione soprattutto - anche se in quel caso forse si è dinanzi ad una battaglia tra competitor!) verso tali tecnologie.

In fondo, però, tale atteggiamento di chiusura era lo stesso che le aziende e non solo loro avevano anni fa verso tutto il mondo Internet nella fase iniziale della sua espansione.
Il paradosso estremo poi è che spesso le aziende che bloccano e chiudono piattaforme come Facebook o Messenger sono le stesse che stanno magari progettando di vendere o fornire, ai loro stessi Clienti, piattaforme di collaborazione Web 2.0!!!
E’ evidente la contraddizione e quindi si è fiduciosi, insieme a Dion Hinchcliffe, che tali comportamenti, se vogliamo in fondo anche schizofrenici, prima o poi saranno riconsiderati…

Software Architecture: to be fast...

2008-10-05T22:21:00.010+02:00

Anni fa. Ennesima intervista a Bill Gates in cui la speaker chiede quale sia il comportamento, la metodologia, insomma la cosa da fare più importante nell'ambito dello sviluppo software.
Domanda tutto sommato banale, la risposta, a giudicare dal volto seccato di Gates e dal conseguente suo famoso sorrisetto ironico, potrebbe essere anche essa banale.
Gates si concentra un attimo e, dopo pochi secondi, da una risposta che, nella sua apparente banalità e semplicità, è e resta invece assolutamente geniale.
La risposta di Gates è semplicemente:

"to be fast..."

L'intervistatrice si mostra a sua volta un pochino seccata, per qualcosa che Gates sembra aver buttato lì tanto per rispondere, ed incalza Gates chiedendogli nuovamente, si... che è ovvio che sia necessario essere rapidi e veloci nel corso dello sviluppo di un qualsiasi software, ma che insomma... cos'altro, sempre secondo Gates, è realmente importante, dopo l'essere fast, nell'ambito dello sviluppo software?

Gates stavolta risponde... ancor più gelido se possibile:

"to be faster..."

Napoleone Bonaparte aveva già risposto, un po' di tempo prima, ad analoga domanda, ovviamente su quali erano i tre parametri più importanti di cui tener conto sul campo di battaglia, la risposta di Napoleone fu:

" ... vitesse, vitesse, vitesse!!!"

Vitesse, ovviamente, in francese significa velocità...

Velocità di motoscafo,1923 Benedetta Cappa Marinetti.

Architects: Paul Allen – Software Architect, Microsoft (1971-1983)

2008-09-08T00:48:00.024+02:00

L'inizio
Questa è una storia che se non fosse realmente accaduta nessuno ci crederebbe.

Sembrerebbe una leggenda, ed in effetti è assolutamente indubitabile che molto di quello che racconteremo a breve ha i toni del leggendario e ciò malgrado il fatto che il personaggio, Paul Allen, essendo uno dei 10 uomini più ricchi del mondo, è ovviamente, e rappresenta, di certo, qualcosa di molto concreto.

…e, nel caso in cui ce lo dimenticassimo, ci sono i suoi 30 miliardi di dollari di patrimonio stimato a tutt’oggi a ricordarcelo.

Altra cosa che dovremo avere sempre presente, nel raccontare la storia di Paul Allen, il vero ed unico numero due della Microsoft di tutti i tempi, ed il suo primo Software Architect, è il fatto che lui e Bill Gates sono amici da sempre, ed hanno condiviso la loro passione per l’informatica da quando erano due giovanissimi teen agers.
L’informatica è la loro passione comune ed è una passione che traspare tutta anche dalla foto seguente, una rarissima immagine del 1968 in cui Bill ha 13 anni (Gates è nato nel 1955) e Paul ne ha 15 (Allen è del 1953).

Aspetto da sottolineare e che traspare tutto ed è cosa ed atteggiamento ben noto a chi lavora nel settore dello sviluppo software (pair programming, programmazione in coppia, eccoli lì… anche Bill&Paul lavoravano con questo metodo!!!), c’è Paul alla tastiera che scrive il codice.

Ed in effetti il primo vero Software Architect, di quella che, al momento della fondazione, si chiamava Micro-Soft, è stato Paul Allen.

L’unica persona, oltre alla madre (che ha avuto un ruolo fondamentale nella creazione di quel colosso che è oggi la Microsoft) di cui si dice che Gates si sia mai fidato in vita sua.
Paul Allen, forse l’unico vero e solo amico di Bill Gates, ed il suo primo Architect!
Allen ha avuto un ruolo chiave nella scalata di Microsoft al successo e non ha mai creato problemi di leadership a Gates.
Problemi di leadership, per inciso, che sono molto sentiti nel mondo dell’informatica, per il particolare tipo di personalità "aggressiva" che hanno e devono avere sempre e necessariamente i buoni programmers.
Allen ha sempre accettato la leadership di Gates, ciò malgrado sia più grande di età, due anni, rispetto a Bill.
Ad Allen, in fondo, forse interessava solo l’aspetto tecnico-creativo ed in effetti tra Allen e Gates c’è stato, probabilmente, lo stesso tipo di simbiosi tecnica e capacità commerciali e di raiders nelle trattative che vi è stato per un'altra coppia storica dell’informatica, Steve Jobs e Steve Wozniak (Apple).

Gates, Allen e la Micro-Soft
Allen è colui che quando fondò, insieme a Gates, la Micro-Soft, ed erano entrambi poco più che ventenni, accettò senza fiatare il diktat di Gates. Bill infatti, su consiglio della madre, modificò, poco prima di trascrivere gli atti formali dinanzi ai notai, la ripartizione percentuale delle quote della società.
Le quote iniziali della Micro-Soft erano 50% Gates e 50% Allen.
Quando la madre di Gates (che si intendeva di affari ed era membro influente di molte potenti associazioni in ambito cittadino a Seattle, la loro residenza) vide la ripartizione fatta dal figlio gli impose di cambiarla…
Disse a Bill che non esistono società al 50% …disse, sempre al figlio, rimproverandolo duramente di non capire nulla, che sarebbe prima o poi arrivato un momento, nell’ambito della vita societaria, di decidere qualcosa di estremamente importante … ed in quel caso doveva essere chiaro chi aveva l’ultima parola e chi no.
Bill capì e torno da Paul dicendogli che lui, Bill Gates, aveva deciso che le quote dovevano essere cambiate, 51% riservate a lui stesso, Gates, e 49% per Paul.
Prendere o lasciare… si guardarono negli occhi mentre Paul prendeva la sua decisione… poche persone al mondo possono reggere lo sguardo di Bil Gates … e Paul accettò.

E fu l’inizio di qualcosa che adesso è, di fatto, leggenda.
Non la ripercorreremo tutta, solo alcuni aspetti cruciali, anche per capire meglio il ruolo di un Architect, quale era ed è Allen, e di quanto tale ruolo sia spesso decisivo.
Una buona scelta tecnica di un buon Architect può salvare una situazione grave ed apparentemente irrecuperabile.
Una cattiva scelta, oppure peggio ancora, l’assenza di un Software Architect e la situazione da critical diviene vero e proprio collasso tecnico.

Microsoft DOS
Allen è la persona che indirizzò Gates, dopo che lo stesso aveva concluso l’affare con IBM, alla scelta di acquistare la code – base di ciò che poi diverrà il DOS. Comprarono la code-base da un programmatore che aveva strutturato e prodotto, senza alcun successo commerciale, qualcosa di simile a ciò che occorreva loro, un clone del C/PM di Gary Kildall (Digital Research).
Lo comprarono per 40.000 dollari!!!
Fu Allen ad estenderlo, lavorando come un matto sui terminali dell’università, e fu lui soprattutto che compì un vero e proprio miracolo tecnico quando, la mattina in cui stava partendo per la sede IBM per consegnare il prodotto (e ci andò solo Allen perché stavano risparmiando anche sui soldi dei biglietti aerei) si accorsero, troppo tardi, Gates ed Allen, che si erano dimenticati di scrivere la sequenza di bootstrap.
Lavorando sui terminali universitari (avevano risparmiato anche su questo!) il bootstrap lo realizzava il mainframe centrale. Ma il DOS doveva essere autopartente!!!
Se lo erano semplicemente … dimenticato !!!
Allen allora realizzò un vero e proprio capolavoro tecnico. Gates stava già pensando a manovre e telefonate dilatorie ad IBM, ma erano già al terzo rinvio, avrebbero quasi certamente perso la commessa più importante della loro vita.
Allen prese allora la decisione, la decisione di una vita, disse a Gates di non preoccuparsi, che avrebbe scritto lui la sequenza di bootstrap… e lo avrebbe fatto… accidenti… da solo in aereo con carta e matita ed in 3 ore circa!!!
Gates lo guardò partire, incredulo, ma Allen era convinto di potercela fare … e Paul scrisse in aereo, su fogli rimediati all’ultimo momento, incredibilmente a memoria, il codice della sequenza di bootstrap!
Arrivato per il test nella sede IBM trascrisse con calma, mentre i tecnici presenti lo scrutavano scettici, il codice nel PC prototipo che IBM gli mise a disposizione e tutto funzionò … miracolosamente senza errori!!!

Non si diventa a caso uno dei dieci uomini più ricchi del mondo!!!

La malattia
E la storia va avanti sino al 1983 …la Microsoft è già una potenza del settore ICT negli Stati Uniti e nel mondo e sotto la guida di Gates si muove con una spregiudicatezza che è indicativa delle modalità aggressive con cui intendono sopraffare il mercato.
Sono, infatti, già di quel periodo, le denunce per approcci di marketing assai discutibili, utilizzati da Microsoft, (ma tipici ancor oggi di molti ambienti ICT!!!) secondo il metodo F.U.D. Fear, Uncertainty and Doubt - "paura, incertezza e dubbio" - e cioè sostanzialmente diffondere notizie, prevalentemente false, sull’incapacità tecnica o su gravi problemi tecnici dei software dei concorrenti per impedirgli di conquistare o difendere mercato.
Nel 1983 accade qualcosa di imprevisto, qualcosa che non ti aspetti…qualcosa che però ci ricorda che siamo uomini… tutti uomini.
Paul Allen si ammala… e gravemente…un cancro, il Morbo di Hodgkin.
Dura due anni la lotta di Allen contro la malattia. Intanto Gates è vicino all’amico e gli dice di non preoccuparsi… che ci penserà lui alla società…sono i due anni più duri per Gates e per Allen…anni in cui Allen la sfanga nella sua lotta per la vita …e Gates stravince contro tutti gli avversari commerciali.
Dopo due anni così Gates è ben felice di riaccogliere il suo Architect, che torna dopo aver vinto la sua lotta contro la malattia.
Ma Allen, che possedendo il 49% è già ricchissimo oltre l’immaginabile, da al suo amico una risposta inaspettata… gli dice che non ha più voglia di lavorare!!!
Che, avendo affrontato la morte, ha imparato il valore della vita ed adesso vuole godersela, vuole spendere tutti i soldi guadagnati, ha le sue passioni (musica, basket, football, donne, viaggi…) e non gli frega più nulla del lavoro!!!
…e quindi prega Bill di liquidarlo economicamente e di lasciarlo andare!!!
Per Gates è un brutto colpo, pensa inizialmente che il suo vecchio amico sia impazzito e prende tempo, anche perché liquidare il 49% di Microsoft non è una operazione economicamente tanto fattibile nel breve.
Ma poi passa il tempo e Gates capisce che il suo amico fa sul serio, che davvero ha staccato la spina, quindi si passa al piano B orchestrato da Gates… che è la parte finale della nostra storia come vedremo…
Nel frattempo, negli ultimi 20 anni, Allen ha realizzato e sta realizzando tutti i suoi capricci… compra squadre di basket (i Portland Trailblazers) ed una di football, i Seattle Seahawks.
Edifica e fonda un museo dal costo complessivo di 500 mil. di dollari dedicato ad uno dei suoi idoli, Jimi Hendrix, finanzia cospicuamente, tra l’altro, la ricerca di forme di vita extraterrestri (23 mil. di dollari al Seti Institute di Carl Sagan) ed una misteriosa società ICT, Transmeta, che è anch’essa una leggenda come il suo fondatore e vedremo poi perché…

L'incidente giudiziario
Peraltro Allen è personaggio molto discreto che non ama far parlare di sé e lo dimostra, circa 10 anni fa, quando, suo malgrado, incappa in un guaio giudiziario. Una sua segretaria lo denuncia per violenza sessuale, è il periodo in cui negli States sembra facile ottenere (vedi caso Mike Tyson) cospicui risarcimenti con denunce del genere.
Ma Allen è uomo pubblico e si ritiene che andrà, con il suo stuolo dei migliori avvocati, sino in fondo, senza patteggiare come è sempre possibile nel sistema americano di Common Law.
Ne sono convinti tutti i media americani e mondiali che cominciano a seguire morbosamente la vicenda.
Si arriva alla data dell’udienza preliminare dove, secondo la prassi americana, il magistrato chiede alle parti di, eventualmente, chiudere la partita con una cifra a risarcimento di tutto, è la prassi, ma Paul Allen è uomo pubblico, rifiuterà, credono tutti, senz’altro per proteggere il suo buon nome.
I difensori della segretaria sparano, senza convinzione, una cifra pro-forma….5 milioni di dollari … è appunto un pro forma.
Si attende l’ovvio NO dei difensori di Paul Allen, i migliori d’America.
Ed a questo punto accade qualcosa che si è visto e si vedrà raramente nelle sedi giudiziarie, gli avvocati di Paul Allen aprono una valigetta, tirano fuori un assegno, compilano la cifra e lo consegnano al magistrato che, incredulo, legge l’importo!!!
Quindici milioni di dollari!!!
Si pensa ad un errore ma gli avvocati di Allen chiariscono.
Essi hanno avuto esplicito mandato, da parte del loro cliente Paul Allen, di pagare 3 volte qualsiasi fosse la somma richiesta dalla controparte per chiudere, definitivamente, la questione in quella sede.
Perché il loro cliente non avrebbe avuto il tempo di dedicarsi alla vicenda!!! Aveva ed ha di meglio da fare…
E di sicuro guardando il suo mega yacht (il più grande del mondo) di cose da fare migliori di una vicenda giudiziaria ne ha!!!

Il sottoscritto estensore di questo post seguì la vicenda, 10 anni fa circa, sui notiziari web e sui giornali come Corriere e Repubblica che dedicarono… e lo ricordo bene davvero… più di un reportage dall’udienza in cui accade quanto descritto.
Uno, molto bello, da parte anche di uno dei migliori giornalisti italiani, Vittorio Zucconi, scritto davvero bene.
Di quella notizia oggi, e la cosa è abbastanza inquietante, non vi è più alcuna traccia sul web.
Provate a cercare…
Allen è un personaggio molto discreto ed anche i motori di ricerca lo sono…

Allen, Trasmeta e Linux
E veniamo a Transmeta… la società più importante di Paul Allen che continua, pur avendo ufficialmente lasciato Microsoft, a tenere un piede nel mondo ICT.
Per anni, prima di annunciare al pubblico di produrre microprocessori a basso consumo e quotarsi al NASDAQ, Transmeta rimane un segreto impenetrabile intorno al quale si accumulano rumours e misteri.
E' la società dove lavora, ma guarda un po’ i casi della vita, e sin dal 1997, Linus Torvalds.
Si, proprio quel Linus Torvalds, l’Architect (un altro ancora!!!) di Linux per intenderci, assunto dall'ex collega Architect Paul Allen con un contratto di milioni di dollari.
Transmeta si dice sia la società che assume programmatori e tecnici di altissimo livello togliendoli prevalentemente ai concorrenti di Microsoft.
E’ la società che si permette, per anni, una home page che è un capolavoro di anti-marketing.
E’ la società che, come il suo principale finanziatore Allen, non ama far parlare di sé sul web…
Tra le leggende che girano nei meandri della rete ve n’è una veramente incredibile… forse la più incredibile di tutte… e ciò la dice lunga sul fatto che le informazioni contenute sul web e nel web chissà cosa siano in realtà.
…comunque, si diceva, la leggenda più paradossale che circola sulla rete è che chiunque scriva di Paul Allen, del suo incidente giudiziario, di Transmeta, di Linus Torvalds che lavora per Transmeta … riceverà una telefonata da un qualche emissario misterioso… che pagherà 3 volte qualsiasi cifra per far sparire la notizia, oppure lo assumerà, se tecnico ICT, in Transmeta a peso d’oro!!!
E questo è veramente davvero incredibile…
Oops… scusate se interrompo adesso questo post …ma mi squilla il cellulare…

Fatturati 2007 dei principali operatori italiani settore Information Technology

2008-08-31T21:09:00.019+02:00

Ecco, com'è tradizione per il mese in corso, l'anteprima della classifica delle prime 10 società IT redatta sulla base dei dati di fatturato (in milioni di euro) dell'anno 2007 (fonte - Computer World Online).

2007

1 IBM Italia 1.756
2 Accenture Italia 982
3 Microsoft 786
4 HP Italiana 745
5 Gruppo Engineering 732
6 Elsag Datamat 654
7 EDS Italia 565
8 Almaviva 473
9 Gruppo SIA-SSB 384
10 Reply 274

E' estremamente interessante, anche per comprendere in una certa misura le evoluzioni del mercato, confrontare gli ultimi dati con l'andamento degli anni 2006 e 2005.

2006

1 IBM Italia 1811
2 Accenture Italia 798
3 Gruppo Almaviva 707
4 Microsoft 700
5 HP Italiana 512
6 EDS Italia 499
7 Gruppo Engineering 426
8 Enterprise Digital Architects 295
9 Atos Origin Italia 287
10 Value Team 259

2005

1 IBM Italia 1868
2 Accenture Italia 689
3 Almaviva 541
4 HP Italiana 485
5 EDS Italia 474
6 Gruppo Engineering 388
7 Atos Origin Italia 312
8 Gruppo Siemens Business Services Italia 284
9 Enterprise Digital Architects 243
10 Oracle Italia 230

Paradigma SOA ed evoluzione verso architetture WOA (Web Oriented Architecture)

2008-08-26T22:59:00.008+02:00

E’ sempre interessante osservare l’evoluzione dei modelli con i quali i developer, nel corso degli ultimi decenni, hanno dovuto confrontarsi nell’ambito dello sviluppo ed integrazione di applicativi e piattaforme software.
Si è passati, ed in fondo è, forse, il percorso professionale tipico di tutti quelli che, come il sottoscritto, hanno passato da poco la quarantina, dalla programmazione strutturata alla programmazione object oriented.
Ricordiamo (con nostalgia!) il mitico Fortran 77, appreso all’università, che “girava” su di un UNIVAC 1100 a schede perforate!!!
Cambio di paradigma “rivoluzionario”, questo relativo alle modalità di programmazione, che non tutti quelli della nostra generazione hanno poi, effettivamente, compiuto!!!
Sempre in tema di ricordi rammentiamo, ancora oggi, gli sforzi personali, in veste di tutor, verso colleghi più “anziani”, cobolisti DOC, peraltro professionisti eccezionali, per convincerli del fatto che il maneggiare una classe, un oggetto, i concetti di istanze delle classi, incapsulamento, ereditarietà, polimorfismo li avrebbe condotti poi ad essere padroni dei moderni linguaggi di programmazione e li avrebbe resi, almeno per determinate e numerose tipologie di applicativi, notevolmente più produttivi.
Ricordiamo bene gli sguardi interrogativi di alcuni di quei colleghi, per i quali il cambio di paradigma non avvenne…
Quell’atteggiamento si avverte spesso, anche oggi, per quello che è stato il salto successivo, che come sottolineano giustamente numerosi analisti del settore, per molte organizzazioni non risulta ancora compiuto, oppure compiuto in maniera assai incompleta e superficiale.
Come dicono in maniera estremamente efficace gli anglosassoni:

“SOA is NOT working in most organizations."

E queste organizzazioni, in cui i paradigmi SOA non sono adottati oppure, forse, sono al primo stadio di integrazione SOA, hanno un solo destino all’orizzonte…

Saranno inevitabilmente molto distanti, con pesantissimi gap da recuperare, da una fase che, invece, per molte strutture “illuminate” è già in corso.
La Web Oriented Era.
La fase ed i paradigmi architetturali successivi alle Service Oriented Architecture, per certi versi già obsolete!!!
L’Era delle architetture WOA, Web Oriented Architecture…
Dove l’interazione, l’interoperabilità è e sarà tra tutte le generiche risorse (Resources) e gli engine di mashup.
Engine dove risiederanno i core dei sistemi di interazione …
Eventualmente workflow e code di aggregazione/trasformazione dei contenuti (siano essi data - esposti tramite Web Services - oppure content – gestiti mediante feed RSS/RDF compliant !!! ).
Uno degli schemi più rappresentativi dell'evoluzione in atto è la figura sottostante, di cui siamo debitori ad uno dei principali “guru” ed osservatori della rivoluzione in corso, Dion Hinchcliffe.

Web 2.0 e Gartner Hype Cycle 2008

2008-08-20T17:03:00.004+02:00

Tra le tecnologie analizzate dagli esperti di Gartner una in particolare ha già raggiunto un grado di maturità tale da farla ritenere ormai prossima alla definitiva affermazione:

- Web 2.0

“I concetti propri del Web 2.0 sono stati adottati entusiasticamente dal mercato consumer - secondo gli analisti di Gartner - e questo, come è già successo per altri modelli e tecnologie costituirà un potente driver alla loro diffusione all’interno delle aziende, dove stanno comunque già suscitando un notevole interesse.

Uno dei principi basilari del Web 2.0 è infatti quello della collaborazione mediante strumenti e applicazioni quali:

- Blog
- Wiki
- Social network
- Content tagging
- Mashup

Strumenti che indubbiamente favoriscono la collaborazione partecipativa e sono quindi in grado, se correttamente impiegati, di migliorare sensibilmente la produttività di chi lavora nelle aziende.

Tali strumenti faranno sì che nel giro di pochi anni potrebbe effettivamente aprirsi una nuova era per l’IT caratterizzata da sistemi, applicativi e processi participant-driven”.

Gartner Hype Cycle 2008

2008-08-20T16:14:00.014+02:00

E' da poco stato pubblicato l'Hype Cycle 2008 della Gartner ... qui di seguito un estratto delle loro analisi e previsioni sulle tecnologie emergenti... l'intero documento (40 pag. circa) è acquistabile sul sito della Gartner, http://www.gartner.com/, ad un costo pari a 1995$...

Lo schema di presentazione è quello solito delle tavole Gartner e passa per le seguenti 5 fasi:

On the Rise - l’Invenzione (Technology Trigger)
Erasable Paper Printing Systems
Context Delivery Architecture
Behavioral Economics
Mobile Robots
Augmented Reality
Surface Computers
Cloud Computing
3-D Printing

At the Peak - la Sopravvalutazione (Peak of Inflated Expectations)
Microblogging
Green IT
Social Computing Platforms
Video Telepresence

Sliding Into the Trough - la Disillusione (Trough of Disillusionment)
Solid-State Drives
Public Virtual Worlds
Web 2.0
Service-Oriented Business Applications
Virtual Assistants
RFID (Case/Pallet)
Corporate Blogging
Idea Management
Social Network Analysis
Wikis
Electronic Paper

Climbing the Slope - la Riprogettazione (Slope of Enlightenment)
Tablet PC
SOA
Location-Aware Applications

Entering the Plateau - la definitiva Affermazione (Plateau of Profitability)
Basic Web Services

Figure 1. Hype Cycle for Emerging Technologies, 2008

[Gartner Highlights 27 Technologies in the 2008 Hype Cycle for Emerging Technologies

Green IT to Gain Momentum Through 2009, Driven by Concerns of Climate Change and Opportunities to Save Costs Through Energy Efficiency

Egham, UK, August 11, 2008 — Gartner, Inc. has identified 27 emerging technologies and predicts that eight of these will have a transformational business impact and should be strongly considered for adoption by technology planners in the next 10 years, according to the report "Hype Cycle for Emerging Technologies, 2008."

"Although Web 2.0 is now entering the Trough of Disillusionment, it will emerge within two years to have transformational impact, as companies steadily gain more experience and success with both the technologies and the cultural implications," said Jackie Fenn, vice president and Gartner Fellow. "Later — in between two and five years — cloud computing and service-oriented architecture (SOA), which is moving up the Slope of Enlightenment, will deliver transformation in terms of driving deep changes in the role and capabilities of IT.
Finally, public virtual worlds, which are suffering from disillusionment after their peak of hype in 2007, will in the long term represent an important media channel to support and build broader communities of interest."
Technologies and trends at or around the peak of the Hype Cycle in 2008 (see Figure 1) that will reach the plateau in two to five years are:

Green IT — Along with broader societal pressure for environmentally sustainable solutions, IT has the opportunity — and in many cases, a requirement — to improve the "greenness" of its own activities, as well as to contribute to broader company and industry environmental initiatives.

Cloud computing — As companies seek to consume their IT services in the most cost-effective way, interest is growing in drawing a broad range of services (for example, computational power, storage and business applications) from the "cloud," rather than from on-premises equipment. Many types of technology providers are aligning themselves with this trend, with the result that confusion and hype will continue for at least another year before distinct submarkets and market leaders emerge.

Social computing platforms — Following the phenomenal success of consumer-oriented social networking sites, such as MySpace and Facebook, companies are examining the role that these sites, or their enterprise-grade equivalents, will play in future collaboration environments. The scope is also expanding to incorporate the notion of social "platforms," or environments for a broad range of developers to build on the basic application.

Video telepresence — High-end videoconferencing systems (for example, from HP, Cisco, Teliris and others) that utilize large, high-definition (HD) displays and components to show life-size images of participants in meeting rooms or suites have proven significantly more effective than earlier generations of videoconferencing technology in providing a strong sense of in-room presence between remote participants. High cost is currently the barrier to broader adoption.

Microblogging— Pioneered by Twitter (although other services such as FriendFeed or Plurk are also available), microblogging is a relatively new addition to the world of social networking, in which contributors post a stream of very short messages (fewer than 140 characters) providing information about their current activity or thoughts, which can then be subscribed to by others. The phenomenon has caught on among certain online communities, and leading-edge companies are investigating its role in enhancing other social media and channels.]

Web Widgets

2008-08-07T16:47:00.004+02:00

Il sogno di ogni editore online è quello di "write once"e pubblicare tutti i contenuti poi sui vari siti, portali e/o web application contemporaneamente.

Ciò è, da tempo, possibile grazie all'RSS (che è un sottoinsieme dell'RDF... siamo in pieno Semantic Web!!!) ed alla continua ascesa e diffusione, oramai "virale", dei web widget.

Pubblicare qualsiasi tipo di contenuti attraverso uno o più feed RSS è una delle scelte strategiche che può consentire agli editori online di aumentare considerevolmente il raggio di distribuzione dei propri contenuti.

Inoltre i web widget, basati sull'RSS, costituiscono, di fatto e sempre di più, una carta vincente, non solo per aumentare l'esposizione e la visibilità dei contenuti, ma anche per poter monetizzare e quindi ricavare guadagni da ciò che si è pubblicato.

Il 2008 è considerato l'anno spartiacque per i principali editori online e ci si attende di vedere nuovi strumenti che consentiranno agli editori ed ai loro lettori di confezionare e distribuire i contenuti in molti modi diversi.

Le modalità per riuscire a cogliere al volo le migliori opportunità in questo settore inesplorato possono essere identificate anche dalle seguenti regole cardine di Fred Wilson, guru del settore:

1 - Microchunk it - Reduce the content to its simplest form.

2 - Free it - Put it out there without walls around it or strings on it.

3 - Syndicate it - Let anyone take it and run with it.

4 - Monetize it - Put the monetization and tracking systems into the microchunk

1 - Fare "microchunking" - Rendere la struttura dei contenuti il più semplice possibile.
2 - Liberare i contenuti - Pubblicare tutto senza mettere vincoli o regole ai contenuti stessi.
3 - Fare "syndication" - Consentire a chiunque lo desideri di prendere i contenuti e ripubblicarli come meglio egli lo ritenga opportuno.
4 - Monetizzare i contenuti - Strutturare sistemi di "tracking" e conseguente monetizzazione per i contenuti pubblicati.

I web widget sono strumenti fondamentali per fare tracking e syndication dei contenuti online.

Gli esperti del settore ritengono anche che, presto, diverranno una delle principali modalità, se non probabilmente l'unica, con cui conseguire margini e ricavi nel settore dell'editoria online.

Widget Marketing: la rivoluzione in corso

2008-08-06T11:49:00.020+02:00

Il web sta mutando a velocità vertiginosa e da un web sostanzialmente passivo per gli "user" (Web 1.0) si sta passando ad un Web "collaborativo" (Web 2.0).
... e le piattaforme di "social computing" sono solo un esempio di tale rivoluzione in atto secondo lo schema seguente:

Uno degli strumenti principali per rendere più efficace le modalità di personalizzazione e "mashup" da parte degli "internauti" dei contenuti web è senz'altro il "widget".
Cosa è un widget? La miglior definizione è secondo noi la seguente di Will Price, nuovo CEO di Widgetbox

che e’ un’interessante piattaforma per creare widget in maniera semplice ed efficace. Price definisce i widget come:

"Widgets are portable applications that are user-defined, user-assembled, and consumed independent of the source of the underlying content, commerce, and application functionality. The combination of user-control and decentralized interaction to important services represents an important paradigm shift in how users discover, select, and consume the best of the web."

Il mercato dei widget è un mercato nuovo ed ancora poco sfruttato... infatti l’analisi sul rapporto relativo alla diffusione tra utenti/spese marketing nel settore dei widget è, sempre secondo le indicazioni di Will Price, la seguente:

“While widget penetration is at 65% of Internet users and growing, spend in the widget category in 2007 was less than $20m, or 0.1% of the total online ad spend market.”

E' chiaro quindi che al momento il "widget marketing" sia un mercato estremamente sottovalutato ed in ogni caso destinato ad una forte crescita già nell'immediato futuro. Ecco, comunque, il post integrale su Techcrunch relativo alle analisi di Will Price.

Recensione: Wikinomics 2.0 - La collaborazione di massa che sta cambiando il mondo - Don Tapscott e Anthony D. Williams

2008-08-05T08:52:00.009+02:00

Di solito, quando leggo un un manuale tecnico, mi capita di fissare mentalmente i concetti chiave, riflettendo con attenzione su quali siano i "connector" logici verso cui quella particolare lettura mi sta conducendo.

E' un processo di associazione mentale che spesso può portare su sentieri talvolta lontani da quelli specifici della lettura in corso.
E' la parte creativa del processo di lettura e questa particolare dimensione logico-associativa fa si che essa sia una attività umana, per così dire, "open"... nel senso che non è necessariamente guidata ed "incardinata" come può essere, ad esempio, la visione di un film dove sono coinvolti vari processi sensoriali (vista, udito etc. etc.).
Per abitudine poi, per rivedere a posteriori quanto mi ha particolarmente colpito durante la lettura di un testo, compio un gesto che di solito, nei confronti del libro, non è molto gentile...e cioè ripiego le estremità del foglio per segnalare la pagina!!!

Normalmente, anche perchè cerco di limitare la "brutalizzazione" del libro, sono circa una quindicina le pagine che "marco" perchè c'è una frase oppure un concetto che mi ha particolarmente colpito...

Su "Wikinomics 2.0" le pagine sono state quasi un centinaio sulle circa 400 del libro!!!

La forza dirompente e nello stesso tempo "concreta" dei concetti esposti in questo manuale è proprio qui, nei possibili, e per tutti siano esse aziende oppure singoli addetti del settore IT, spunti operativi !!!

Questo manuale, quindi, è stata forse la mia lettura tecnica-organizzativa più importante degli ultimi anni.

Tutto parte dal concetto (ovviamente concetto "manifesto" perchè non ci si ferma solo alle tecniche di "social computing") di Wiki come esemplificativo del cambiamento dei processi lavorativi da sequenziali (workflow di singole attività mono-thread secondo la tecnica del "passaggio del testimone") a collaborativi e concorrenti (thread paralleli) mediante i potentissimi strumenti (wiki, blog, feed etc. etc.) di vero e proprio "social computing integrato".

Gli esempi ed i documenti che gli autori portano a dimostrazione delle loro tesi sulla rivoluzione in atto sono innumerevoli e ne cito solo alcuni:

- "Jonathan Schwartz, CEO di Sun Microsystems, ha stabilito che ciascun dipendente tenesse un blog ... ciò ha aiutato l'azienda a riconquistare la propria forza competitiva nel settore IT"

- "Gli editori che pubblicano opere letterarie, film, software e programmi televisivi sono le prime vittime di una rivoluzione che sta attraversando a passo spedito tutti i settori... attraverso la peer production (produzione tra pari) possiamo realizzare un sistema operativo, una enciclopedia, e persino oggetti materiali come una motocicletta... "

- "Mentre la vecchia Rete era fatta di siti web, di click, e di occhi puntati sul monitor, la nuova Rete è fatta di comunità, di partecipazione e di peering..."

- "Il peering - collaborazione tra pari - funziona perchè fa leva sull'organizzazione autonoma, uno stile di produzione molto più efficace della gestione gererchica ai fini dello svolgimento di alcune attività. Il suo maggiore impatto si verifica nella produzione di beni informativi ed i suoi primi effetti si possono riscontrare soprattutto nella produzione di software, contenuto mediatico, intrattenimento e cultura... ma non c'è ragione per cui la peer production debba fermarsi a questo!!!"

Si potrebbe continuare con ulteriori citazioni ma la realtà del cambiamento, che molte aziende ed anche Corporation illuminate stanno realizzando, è strabiliante!!!

Si veda, ad esempio, il caso descritto di Procter & Gamble che ha adottato criteri di creazione ed ideazione dei prodotti guidati da tecniche di social computing ed è passata, nel corso degli ultimi 5 anni, dal quasi fallimento a redditività mai realizzate prima ... e tutto questo ricorrendo a software e criteri di collaborazione dei propri R&D con la Rete esterna che hanno riportato questa corporation ad essere leader indiscussa nel proprio settore.

Questo manuale descrive un cambiamento in atto ... un mutamento che attraverserà le aziende ed il modo di lavorare di tutti noi con la stessa importanza e virulenza che ha avuto per l'umanità, in passato, la Rivoluzione Industriale...

Strategic Planning – Processi e deliverables

2008-07-14T09:55:00.000+02:00

Lo scopo di una infrastruttura IT è, fondamentalmente, quello di supportare il raggiungimento degli obiettivi del business attraverso un efficiente ed efficace uso dei sistemi ICT dispiegati.
Di conseguenza il business ha la necessità di dover essere tradotto in tecnologia e ciò può avvenire solo avendo definito, in precedenza, un Modello di Infrastruttura.

Modello di Infrastruttura ICT

La figura precedente mostra il fatto che le business unit ed i processi dipendono strettamente, ed ovviamente, dalla qualità e modalità di correlazione degli ICT services. Gli ICT services sono, a loro volta, dipendenti sia dalla Tecnologia d’Infrastruttura sia dagli elementi costituenti la stessa Infrastruttura. Tali ultimi elementi sono, ovviamente, forniti e dispiegati sia da team interni sia da fornitori esterni.
Le modalità di interazione tra gli ICT services ed il business sono e devono essere documentati tramite SLAs (Service Level Agreement) mentre le analoghe interfacce tra i team di supporto ed i fornitori devono, altresì, essere documentati e definiti in accordi di OLAs (Operational Level Agreement) e Contratti di Servizio, correlati anche essi dai necessari SLAs.
Nel caso si desiderino ulteriori dettagli relativamente a tali documenti è possibile far riferimento ai modelli di Service Support e Service Delivery contenuti all’interno della ITIL Library di cui il presente documento (white paper) è abstract.

Lo scopo dello strategic planning è quindi contribuire al design degli ICT services della infrastruttura richiesta e necessaria al business. E’ importante che le ICT strategies siano attestate e definite secondo le seguenti linee guida e best practices:

Allineate con la business strategy e le sue pianificazioni
Appropriate allo scopo, realistiche e concrete
Focalizzate sul business
Bilanciate tra obiettivi di breve e lungo termine
Opportune e ragionevoli
cost-effective
includere milestone di implementazione che siano effettivamente misurabili

Come mostrato nella seguente figura l’ICT planning riguarda molti livelli, dalla strategia al planning dell’infrastruttura operazionale ed è notevolmente influenzato, a tutti i livelli, dalla strategia di business e del conseguente strategic planning.

Business ed ICT planning - Livelli

Una strategia ICT è considerata un prerequisito ad un coerente planning relativo all’infrastruttura ICT, al planning tattico ed al planning operazionale.
Il complessivo process planning dovrebbe procedere attraverso i seguenti livelli e step mostrati nella seguente figura.

Planning levels e triggers.

La figura precedente mostra anche che le strategie, policy ed architetture non sono solamente costituite da documenti attivi e/o proattivi ma anche e soprattutto, reattivi.
Ad ogni buon conto si deve sempre considerare che l’infrastruttura ICT è un investimento a lungo termine che evolve parallelamente alle necessità di modifica (change management) guidate dal business ed in funzione del livello di richiesta relativamente ai servizi esistenti.
Quindi come mostrato in precedenza, ci sono differenti entry points all’ICT planning quando esso diviene necessario per:

supportare una nuova business unit
fornire un nuovo business service
migliorare le performance di sistemi e servizi
andare incontro alla domanda o rettificare limitati down relativamente ad alcune richieste caratteristiche operazionali
sostituire componenti/moduli/servizi all’interno di concordati budget operativi

Un approccio strategico dovrebbe essere sempre adottato in merito alla definizione di uno specifico planning relativo ad una infrastruttura ICT.

Questo implica anche il creare architetture per framework di lungo termine dell’infrattruttura ICT necessaria a supportare una determinata strategia ICT.

Lo sviluppo di una strategia ICT è comunque un obiettivo estremamente complesso. Proprio per tal motivo è necessario e vitale che appropriate risorse e tempo siano investiti e dedicati allo sviluppo della strategia.
Le migliori strategie ICT sono guidate dal business e dalle necessità del business. Per tali motivi, come esplicitato dalla figura seguente, gli attivatori per lo sviluppo e revisione continua di una strategia ICT dovrebbero essere proprio lo sviluppo e revisione parallela delle strategie di business e relativi planning.

Lo sviluppo dell’ ICT Strategic Planning.

JobStats - the current state of the UK computing job market

2008-07-11T14:43:00.000+02:00

E' il mercato IT relativo alla Gran Bretagna (il total demand for staff) ... in linea di massima segue il trend dell'economia mondiale che è agganciata, per quanto riguarda soprattutto il settore Information Technology, fortemente a quella americana.

Solitamente l'andamento del grafico seguente diviene attuale, nel mercato italiano, dopo circa due mesi... quindi se lo si vuole leggere appunto per il mercato italiano (sia se si è job seeker sia se invece si è IT Human Recruiter) basterà aggiungere due mesi al valore indicato dal grafico!!!

Il sito di riferimento è:

http://www.jobstats.co.uk/

dove è possibile rintracciare anche i profili IT più ricercati in UK ed il loro price medio, ovviamente sul mercato anglosassone.

Total demand for staff in UK

Recensione: Il coraggio e la visione. Il lato segreto dei creatori di successo

2008-07-09T20:06:00.000+02:00

E' impressionante, leggendo questo libro di Jessica Livingston, rilevare le differenze tra le modalità con cui nasce il tipico imprenditore nel settore IT negli Stati Uniti ed invece come e cosa sia l'imprenditore e l'imprenditoria IT in Italia.
I casi che l'autrice prende in esame sono delle vere e proprie avventure, in cui lo spirito di sacrificio personale è unito però alla possibilità, che solo il meccanismo tipicamente americano dei Venture Capitalist consente, di vedersi riconosciuta (e finanziata!!!) nel caso ci sia, la qualità di un prodotto.
Il libro è sostanzialmente una raccolta di interviste ai soci fondatori di alcune aziende leggendarie in campo tecnologico che raccontano come hanno realizzato il loro sogno.
Sogno che il più delle volte, è bene notarlo come costante, non era legato alla possibilità di immediati guadagni ma era invece, sin dall'inizio, legato fondamentalmente ad una idea ed alla fortissima volontà di realizzarla.
Citiamo solo alcune delle persone intervistate: Steve Wozniak (Apple), Caterina Fake (Flickr), Mitch Kapor (Lotus) e Sabeer Bhatia (Hotmail) ...
L'intervista a Steve Wozniak varrebbe da sola l'acquisto di tutto il libro. Woz, come venne soprannominato dal suo altrettanto leggendario compagno Steve Jobs, appare nella intervista come quel personaggio che ci siamo sempre immaginati che fosse... un creativo geniale ed una persona trasparente... un tecnico che dal nulla creava una macchina che è stata la storia dell'informatica, l'Apple 1.

Titolo: Il coraggio e la visione. Il lato segreto dei creatori di successo
Autore: Livingston Jessica
Editore: Mondadori Informatica
Data di Pubblicazione: 2008
Collana: Argomenti generali
ISBN: 8861140920
ISBN-13: 9788861140929
Pagine: 302

The Perils of JavaSchool

2008-07-08T17:30:00.000+02:00

The Perils of JavaSchool

Un interessante articolo, come sempre scritto in modo estremamente piacevole, di Joel Spolsky (ex Program Manager Microsoft - Excel vi dice qualcosa?) uno dei "guru" del software attualmente più ascoltati. Una visita periodica al suo blog, http://www.joelonsoftware.com/ è sempre d'obbligo!
In quest'ultima nota egli si lamenta dei tempi moderni o del fatto che in realtà, come tutti noi, forse sta invecchiando: "A sure sign of my descent into senility is bitchin' and moanin' about 'kids these days,' and how they won't or can't do anything hard any more!"

Recensione: Code Complete di Steve McConnell

2008-07-08T17:28:00.001+02:00

Spesso capita di leggere qualcosa una prima volta, in momenti o periodi in cui magari, per varie motivazioni, non siamo pronti a comprendere in profondità ciò che abbiamo tra le mani. E poi capita di rileggere e scoprire che quel qualcosa è veramente un'incredibile fonte di apprendimento e crescita. Questa è la mia attuale esperienza con Code Complete (di Steve McConnell) che avevo già letto anni fa, di corsa ed in inglese, ed oggi sto rileggendo nella sua recente edizione italiana (MS Press) con il (solito) brutto titolo, che i traduttori italiani purtroppo non ci risparmiano mai, di "Ingegneria del Codice". Cito solo una frase, a proposito di questo testo, di Peter Wright (Program now) e poi chiudo: "Questo libro merita di diventare un classico e dovrebbe essere una lettura obbligatoria per tutti gli sviluppatori e per chi è responsabile della loro gestione".

Citazioni del mese

2008-07-08T17:26:00.000+02:00

P. Picasso: "Quando i critici d'arte si incontrano parlano di Forma, Struttura ed Espressione. Quando gli artisti si incontrano parlano di dove si può acquistare a minor prezzo l'acquaragia".

Gibbon: "L'insegnamento è sempre inutile, eccetto nei casi in cui è superfluo".

Oscar Wilde: "Chi dice la verità, prima o poi, viene sempre scoperto".

Scott Ambler (http://www.ambysoft.com/): "A good developer knows that there is more to development than programming. A great developer knows that there is more to development than development".

Recensione: Web Usability - J. Nielsen

2008-07-08T14:33:00.000+02:00

L'autore di questo testo Jacob Nielsen è, attualmente, uno dei massimi guru del Web design. I suoi principi di progettazione web si possono riassumere fondamentalmente in tre parole: semplicità, semplicità, semplicità!!!E' un paradosso ovviamente ma la semplicità, o meglio la pratica della semplicità, come Nielsen definisce il cuore della propria metodologia di progettazione, è quasi un'ossessione per un Nielsen contrariato per la enorme quantità di siti inutilmente complessi e con contenuti informativi nulli. Ed in effetti, se si verifica sul campo l'applicazione alla lettera di tale pricipio proprio sul suo sito http://www.useit.com/ si può, sulle prime, rimanere paradossalmente sconcertati dalla grafica estremamente spartana, quasi monacale!!! Del resto anche il testo Web usability si presenta con una grafica semplice ma evidentemente, dati anche i numerosi esempi presenti riguardanti, purtroppo, principalmente ciò che non si deve fare sul web pittosto che, invece, esempi in positivo, i grafici della casa editrice non devono aver lasciato completamente mano libera a Nielsen!!!Comunque, ad ogni buon conto, è utile sottolineare che Web usability non è né un manuale di tecniche di programmazione né un testo destinato esclusivamente a grafici del web. E' piuttosto un utilissimo compendio di principi generali di project-design che tutti coloro che hanno in qualche modo a che fare con la progettazione di sistemi informatici, dal foglio elettronico alle intranet di grandi aziende, dovrebbero leggere con estrema attenzione. Se, infatti, l'importanza che Nielsen attribuisce all'usabilità da parte dell'utente di pagine web si diffondesse tra i progettisti di tutte le interfacce utente di qualsivoglia prodotto informatico tutto il mondo dell'IT ne trarrebbe gran giovamento. Gli utenti non avrebbero più scuse, data la buona qualità dei prodotti, relativamente alle difficoltà d'apprendimento nell'utilizzazione dei loro programmi!!!Nielsen sottolinea, come filosofia di fondo, che se i processi che conducono alla progettazione di interfacce utente sono inutilmente complessi anche la relativa implementazione del motore software sottostante ne soffrirà inevitabilmente. In conclusione Nielsen, da perfetto appartenente al pragmatico mondo americano, definisce un acronimo (H.O.M.E.) per riassumere i cardini fondamentali dei suoi principi di progettazione affichè gli utenti tornino in certi siti anzichè in altri.Il significato di tale acronimo, riassuntivo di ciò che Nielsen tende a comunicarci con questo testo, è: High quality (contenuti di alta qualità), Often (aggiornamenti frequenti), Minimal (tempi di scaricamento minimi), Ease (facilità d'uso).

Pro:

Oltre a principi generali vi sono, ampiamente documentati, suggerimenti relativi a page design, content-design, intranet design, e da ultimo ma non per importanza, per il doveroso rispetto che il mondo anglosassone, a differenza di noi italiani, ha sempre avuto per tali problematiche, criteri di progettazione web per utenti con disabilità.

Contro:

Forse Nielsen può essere considerato un pò troppo integralista e ci si chiede come sarebbe il web se tutti i web-designer applicassero alla lettera i suoi criteri di progettazione!!!

Autore: Jacob Nielsen

Titolo: Web Usability

Editore: Apogeo

ISBN: 8873036864

Lingua: Italiano

Anno: 2000

Prezzo: € 40,28

Pagine: 418

Allegati: nessuno

Recensione: Sistemi Informativi e aziende in rete - C. Francalanci ed altri

2008-07-08T14:21:00.003+02:00

[Premessa necessaria... si tratta di recensione già pubblicata qualche anno fa dal sottoscritto sulla rivista Computer Programming... ma i principi esposti in questo manuale sono pur sempre attuali...]

L’Ingegneria del software è una disciplina relativamente recente, in continua evoluzione e senza un patrimonio di esperienze consolidate come le altre Ingegnerie. Negli ultimi anni si è cercato di porre rimedio con la quantità di metodologie (L’UML ed il RUP saranno la soluzione?) alla scarsa maturità delle stesse. Il libro ci informa che, anche per questa evidente immaturità, l’atteso impatto rivoluzionario dell’Information Technology è stato notevolmente inferiore alle attese. Ma come? L’IT, che appare oggi essere il traino indispensabile dell’economia mondiale, non ha determinato alcuna crescita della produttività del sistema economico? La Rivoluzione Informatica non regge il paragone con la Rivoluzione Industriale? La risposta potrà apparire un paradosso ed, in effetti, gli studiosi di economia lo definiscono, in letteratura, come paradosso di produttività, ma la dura realtà, principalmente per i professionisti del settore, è proprio questa: non vi è nessuna automatica correlazione tra investimenti in informatica ed accelerazioni positive della produttività nelle aziende che li effettuano. Gli Autori, che sono docenti presso il Politecnico di Milano, partendo da questo presupposto, che rappresenta comunque un dato di fatto, descrivono le principali teorie sul rapporto tra le strutture aziendali ed i processi di elaborazione dell’informazione. Il testo pone quindi l’attenzione su due aspetti di solito poco considerati dagli sviluppatori e che, tuttavia, rappresentano spesso la differenza tra un progetto software riuscito ed uno fallito: l’efficacia delle stesse regole di business implementate dal software e le metodologie utilizzate per catturarle (estremamente interessante l’appendice dedicata dagli Autori all’analisi delle procedure aziendali e la conseguente descrizione del metodo AD - Analisi del Dettaglio). In sostanza il testo sottolinea che l’efficienza e l’efficacia di un software si misurano dalla capacità d’introdurre una nuova tecnologia unitamente al cambiamento organizzativo al quale essa si accompagna. Attraverso un percorso diviso, a grandi linee, in tre parti il libro ci descrive, nella prima parte, la differenza tra le tecnologie informatiche e le tradizionali tecnologie di produzione indicando, tra l’altro, alcune regole e criteri operativi di orientamento generale per la progettazione di sistemi informatici. Nella seconda parte vi è la descrizione dell’architettura complessiva dei sistemi di supporto operativo (ERP, CRM, SEM) e delle regole di business ad essi sottesi (Controllo di gestione, ad esempio). La terza parte si propone come ponte tra i metodi dell’Ingegneria Gestionale e l’Ingegneria del Software descrivendo i criteri di passaggio dall’Analisi del Dettaglio (analisi delle procedure aziendali) al modello Entità – Relazioni.

Pro:
Le tecnologie informatiche sono importanti almeno quanto i principi che costituiscono le basi dell’informazione trattata delle tecnologie stesse. Gli sviluppatori che desiderano approfondire il tema della comunicazione tra l’IT e la complessa realtà dei processi da informatizzare possono trovare in questo testo uno strumento di indiscutibile valore.
Contro:
Nessuno

Scheda
Autore: G. Bracchi; C. Francalanci; G. Motta
Titolo: Sistemi informativi e aziende in rete
Editore: McGraw-Hill Libri Italia srl
ISBN: 8838608849
Lingua: Italiano
Anno: 2001
Prezzo: € 33,50
Pagine: 448
Allegati: nessuno

Boullée, Speer...

2008-07-08T11:58:00.000+02:00

Teorico, architetto rivoluzionario e uomo dell'Ancien Régime, Boullée, è architetto di cui resta praticamente quasi nulla di realizzato ma la cui influenza è stata poi, seppur misconosciuta, enorme... ed è arrivata a noi, tramite un sottile filo rosso, passando finanche per l'Architetto di Hitler, Albert Speer.

Speer, che è considerato uno dei fondatori delle teorie di project management ed organizzazione di sistemi complessi.
L'Architetto che, di fatto, ha consentito, con le sue "mostruose" capacità organizzative, riconosciute al tempo anche dagli avversari del Reich, e mediante aumenti di produzione dell'industria bellica tedesca, al Reich di Hitler di resistere alla pressione degli Alleati.
Ciò malgrado i distruttivi bombardamenti cui lo sottoponevano l'azione combinata degli inglesi e degli americani.

La "forza organizzativa" di una buona architettura!!!

Boullèe, comunque, è stato personaggio visionario ed amatissimo dal mondo del cinema.

Il film "Il Ventre dell'Architetto" girato a Roma da Peter Greenway, è basato sull'ammirazione sconfinata per Boullée da parte del protagonista.

La parte più importante della produzione di Boullèe era costituita da una serie di progetti fantastici destinati ad illustrare la sua visione di Architettura ... progetti di smisurati edifici pubblici in cui veniva proposta un'architettura nuova, basata sulla sperimentazione di forme geometriche elementari e carica di significati morali e simbolici.

Forme elementari, geometrie semplici ... tecnologia ed arte KISS ... keep it simple!!!

Disclaimer

2008-07-07T18:09:00.001+02:00

Avviso e rinuncia di responsabilità
L'autore di questo sito compie ogni ragionevole sforzo affinché esso risulti il più completo ed accurato possibile, ma ciò non implica alcuna garanzia esplicita o implicita, né alcuna affermazione di idoneità per un particolare uso. Le informazioni qui contenute vengono fornite "come tali".
L'autore non potrà essere, in alcun modo, ritenuto responsabile nei confronti di persone fisiche o giuridiche in merito ad eventuali danni o perdite derivanti dalle informazioni contenute nel presente sito. Si precisa, inoltre, che nel caso in cui venga pubblicato materiale coperto da copyright ciò sia da considerarsi nient'altro che un mero errore. Si dà, quindi, sin d'ora, la più ampia disponibilità a rimuovere, previa opportuna segnalazione degli interessati, il materiale di cui sopra.

Ulteriori precisazioni in merito alle recenti disposizioni di legge relative all'editoria italiana
In ottemperanza alla recenti disposizioni di legge relative all'editoria italiana si precisa, altresì, che tale sito non è un periodico e, conseguentemente, qualunque testo vi appaia non ha alcun tipo di cadenza predeterminata nè predeterminabile. Inoltre il sito, non essendo evidentemente una testata giornalistica, è privo di editore. Tutto il materiale immesso nelle aree pubbliche è di proprietà dei relativi autori, se non menzionato diversamente. Tutti i loghi ed i marchi registrati su questo sito appartengono ai rispettivi proprietari. Tutto il resto è proprietà del web-editor Fabio Ciccone.

Responsabilità dell'autore sui contatti acquisiti tramite il sito
Chi consulta il sito si assume tutti i rischi relativi al fatto di entrare eventualmente in contatto con altri utenti attraverso il Sito stesso che è quindi estraneo ai rapporti user-to-user e conseguentemente, nel caso in cui dovessero insorgere controversie tra utenti, gli utenti stessi si impegnano ad escludere i responsabili del sito per ogni e qualsiasi danno dovessero subire in conseguenza di tali controversie. L'Autore non garantisce che il sito sia privo di errori, che il sito o il server siano privi di virus e/o altri difetti tecnici di qualunque natura. Qualora l'utilizzo del sito o del materiale crei dei danni agli strumenti informatici degli utenti oppure ai loro dati l'Autore non sarà in alcun modo responsabile per i costi relativi a servizi di manutenzione, riparazioni e/o sostituzioni.