Greetings, I think I found a solution on another site. I did this:
Exited the entire add or remove programs panel. Then opened a command window and entered: esentutl /p %windir%\security\database\secedit.sdb
After doing this I attempted to add the IIS component and it worked perfectly.
posted by ilmale at
10:02 PM
La prima volta che dissi a mio zio, di professione salumiere, che facevo l’architetto, questi mi guardò un po’ stranito e mi disse: “Strano, pensavo che tu lavorassi con i computer, non con le case”.
Fortunatamente questo non lese i nostri rapporti e finì di prepararmi un po’ di ottimo culatello.
Mentre tornavo a casa cominciai a pensare se la terminologia “architetto” fosse quella più giusta per descrivere il mio lavoro.
In quel periodo lavoravo in una azienda che aveva la sua “fabbrica del software” e che stava sviluppando un nuovo prodotto.
Nella fabbrica lavorava un direttore (che dirigeva), del personale amministrativo (che amministrava), degli analisti funzionali (che facevano analisi funzionale), degli analisti tecnici (che facevano l’analisi tecnica), degli sviluppatori (che sviluppavano), dei tester (che facevano il test) e altri.
E io? Cosa facevo? Perché mi chiamavo, e avevo convinto gli altri a chiamarmi, architetto?
L’architetto Edile
Nell’edilizia, semplificando, abbiamo l’architetto che disegna la casa, abbiamo l’ingegnere edile che fa tutti i calcoli e le misure, abbiamo il capomastro che guida la costruzione e abbiamo gli operai edili che fisicamente si occupano dei mattoni, del cemento e di tutto quello che è necessario a trasformare in casa un insieme di materiali vari.
Nell’edilizia è chiaro il compito di ciascuno:
• l’architetto deve disegnare una casa che sia piacevole da vedere, sia piacevole da usare, sia inseribile nel contesto in cui viene costruita, il tutto indicando, fin dove è possibile, i migliori materiali e le tecnologie più innovative e con un corretto rapporto qualità/prezzo;
• l’ingegnere deve fare tutti i calcoli necessari alla corretta gestione dei materiali utilizzati, tra cui la tipologia di cemento, il tipo di ferri, le dimensioni dei pilastri e delle tramezze e così via. Il suo compito è far sì che l’immobile costruito rimanga “immobile” e non si sfasci dopo poche settimane;
• il capomastro e gli operai si occupano di trasformare disegni e calcoli in un oggetto fisico.
Nel nostro lavoro la suddivisione dei ruoli non è così chiara.
L’architetto Software
Un architetto del software deve fare molte e diverse cose tra cui:
• Capire le esigenze del cliente
• Capire quali sono gli strumenti e le tecnologie più adatte alla soluzione del problema
• Disegnare l’architettura dell’infrastruttura del sistema
• Disegnare l’architettura applicativa della soluzione
• Disegnare l’architettura della presentation della soluzione
Ma contemporaneamente, spesso, deve fare altre cose:
• Capire quali sono le esigenze inespresse del cliente (essere un po’ analista funzionale)
• Capire quali sono i vincoli organizzativi e strutturali del Cliente (essere un po’ analista tecnico e un po’ consulente organizzativo)
• Capire quali sono i vincoli di integrazione e di relazione sia inter-company che intra-company (essere un po’ commerciale, consulente organizzativo, consulente di M&A, consulente finanziario, etc…).
• Fare un prototipo della scelta tecnologica di punta che tutti si ostinano a dire “non può funzionare” per dimostrare il contrario (essere un po’ ingegnere software).
• Sovrintendere al lavoro successivo degli sviluppatori per verificare che un livello, inserito per rendere l’applicazione portabile o pronta a evoluzioni future, non diventi un dinosauro a settecento livelli (essere un po’ capomastro e un po’ direttore della fabbrica)
• Calmare il cliente che non capisce cosa c’entri uno strato di accesso ai dati e un meccanismo per la gestione delle business rules con la sua esigenza di fare fatture (essere un po’ commerciale)
• Calmare l’intero staff di sviluppo che non capisce perché si debba fare tre livelli applicativi invece di quel meraviglioso monolite con tre milioni di righe in una sola funzione che fa tutto senza classi, metodi e tutte quelle cose lì un po’ oscure e francamente noiose
• Calmare i due o tre dello staff di sviluppo che per accedere ai dati fanno un fantastico livello suddiviso in trentadue sotto livelli tra cui il meraviglioso livello 24 che generalizza il concetto di “where” nella ipotesi che un domani ci sia l’SQL in italiano o che esiste un “where” ma anche “who” , “when”, “what” e why” se domani ci fosse il “SQL del Giornalista” con le sue cinque “W” (chi?/dove?/quando?/che cosa?/perché?) (mi scuso con voi e con Clark Gable per la citazione cinefila).
• …
Insomma fare l’architetto significa un po’ essere il padre della soluzione che si va a progettare.
Concepirla, farla nascere e crescere e vederla allontanarsi da casa, ma tenendola d’occhio come un padre premuroso con il figlio un po’ scapestrato, che andrà sicuramente con qualche brutta compagnia e rischierà di cacciarsi in qualche brutto bug.
Bug che ci costringerà a correre di notte al suo capezzale a portargli un bug fixing tanto più doloroso quanto il bug era grosso.
E quindi che fare?
Chi è l’architetto del Software
Fare l’architetto factotum o fare l’architetto sulla sua torre che dispensa disegni e saggezza?
L’architetto del software per prima cosa deve essere persona multi disciplinare.
La sua conoscenza non può essere solo informatica, deve comprendere anche elementi che sono di contorno all’informatica, non dimenticando che nella stragrande maggioranza dei progetti, a essere di contorno al tutto è il software e non viceversa.
Per assurdo, ma non tanto, un architetto del software può fare bene il suo lavoro solo se conosce molto bene il contesto dell’applicazione, le sue terminologie specifiche, il contesto di business e di relazioni, i meccanismi di produzione e gli aspetti organizzativi.
Un classico errore è focalizzare l’architettura su un argomento che compare nell’analisi, ma che non ha nella realtà, un peso così elevato.
Un esempio tipico è l’esigenza di operare anche fuori linea, gestendo la sincronizzazione delle informazione tra operatori fuori linea e quelli sempre in linea.
Questo è un classico e interessante problema di architettura applicativa e sistemistica.
Le molte soluzioni esistenti sono focalizzate sull’operatività off-line e la scelta su quale sia quella corretta è frutto dell’analisi e della comprensione di questa specializzazione.
Tuttavia il primo approccio verso l’operatività off-line deve essere orientato non tanto agli aspetti strettamente tecnologici, quanto verso quelli organizzativi e di business, non tanto per invadere il campo degli Analisti Funzionali che hanno rilevato le esigenze organizzative e di business, quanto per valutare, in base alle diverse scelte tecnologiche, le condizioni di miglior costo/beneficio del problema nel suo insieme.
Make vs. Buy
Inoltre l’architetto deve cercare di mantenere un distacco dalle spinte “aziendali” indirizzate a dare una soluzione a tutto tondo del problema del cliente, spingendo sempre, fin quanto possibile, la soluzione buy contro la soluzione make.
Rifare in casa quello che è già fatto è spesso molto conveniente per il fornitore, ma altrettanto spesso non lo è per il committente.
Le soluzioni fatte in casa, e il software precostruito e riutilizzato, possono rispondere perfettamente alle esigenze architetturali del cliente, e in questo caso possono essere scelte senza problemi, ma possono anche essere molto lontane dalle esigenze e in questi casi si vede l’esplosione di una miriade di “trucchi” per far funzionare correttamente il tutto.
Nella memoria ho vivida una soluzione trovata presso un cliente, dove un’applicazione scriveva dei file su disco e poi chiamava l’altra applicazione con una shell. L’altra applicazione veniva eseguita aprendo per prima cosa i file salvati su disco.
Questa soluzione aveva problemi prestazionali e di sincronizzazione notevoli e ciò che facemmo fu di verificare se esistesse sul mercato una soluzione standard in grado di gestire l’integrazione con le applicazioni esistenti, migliorando la prestazione e semplificando la configurazione e la gestione.
La capacità di conoscere “i materiali”, ovvero di fare scouting sulla rete di componenti applicativi, è un elemento di distinzione netta tra un buon e un cattivo architetto del software.
La costruzione di edifici particolarmente belli e funzionali è, da parte dell’architetto edile, frutto di scouting e di valutazione dei materiali disponibili e innovativi.
Un esempio tra tutti la piramide di entrata al Louvre di Parigi frutto della genialità di Ieoh Ming Pei, ma anche dell’utilizzo di materiali e tecnologie estremamente innovative.
L’architetto si pone come il direttore dell’orchestra, il suo compito è di far si che ogni componente del progetto dia il meglio.
Questo ruolo non è alternativo a quello del Capo Progetto che deve far sì che ogni componente dia il meglio, ma in subordine agli aspetti economici, commerciali e di relazione.
L’architetto può “sognare” di più e sarà, eventualmente in una seconda fase, il Capo Progetto a riportarlo nelle regole complessive del progetto se, in qualche modo, ne esce.
Inizio pagina
Il lavoro dell’architetto
Il contesto di lavoro dell’architetto software è un ecosistema che comprende
• Architettura dell’applicazione
• Architettura dell’infrastruttura e del deploy (per i componenti software)
• Architettura dell’usabilità
• Architettura dell’integrazione (dei diversi componenti del sistema)
Così come l’architetto edile si confronta con numerose e diverse sfaccettature della costruzione così l’architetto software affronta ogni progetto come molti sub progetti specializzati, facendo sì di armonizzarli e renderli coerenti e funzionali.
In particolare l’applicazione deve essere centrale nell’attenzione e nell’operatività, ovvero l’applicazione deve fare ciò per cui è richiesta e pensata nella modalità più efficiente e semplice.
L’architetto software deve evitare le elaborazioni fantasiose e “curiose” quando queste non siano utili allo scopo primario dell’applicazione.
La soluzione innovativa e/o “di effetto” non deve mai puntare all’innovazione e/o all’effetto come fine, ma al miglioramento dell’applicazione per sé.
Non sempre è facile fare questo perché a volte ci si “innamora” della propria soluzione e ci si autoconvince che è esattamente ciò che il cliente si aspetta.
Questo è un grosso pericolo, reale e insidioso.
È abbastanza normale, e comprensibile, che il frutto di una lunga elaborazione appaia come una soluzione perfetta, tuttavia la soluzione pensata ed elaborata con cura può portare in sé anche delle carenze o difetti che trasferiti nella soluzione reale possono diventare molto critici.
È necessaria una forte onestà intellettuale verso se stessi e una altrettanto marcata umiltà.
Un errore di architettura può avere effetti infinitamente più gravi di ogni altro componente nello sviluppo del software.
A fronte di una progettazione azzardata, gli ingegneri del software potranno cercare di fare i pilastri robusti quanto vogliono, ma nella migliore delle ipotesi la soluzione sarà brutta e sgraziata, e in un’applicazione “sgraziata” è sinonimo di “mal funzionante”.
Un’applicazione correttamente progettata dal punto di vista dell’architettura sarà un’applicazione che farà bene ciò che deve fare e lo farà in un contesto che risulterà piacevole all’utente.
Domande
Per fare tutto questo è necessario affrontare i diversi aspetti della progettazione ponendosi molte domande e inquadrando correttamente il problema applicativo.
Per prima deve essere disegnata l’architettura applicativa, ovvero
• Chi fa cosa (profili applicativi);
• Come si deve fare quello che si deve fare (cosa fa e, soprattutto, cosa non fa l’applicazione);
• Ciò che avviene è atomico (siamo in contesto transazionale?);
• Ciò che avviene ha un tempo finito o indeterminato (siamo a fronte di long time transaction?).
Poi si deve procedere al disegno dell’architettura dell’infrastruttura e del deploy, ovvero
• Com’è, concettualmente, il sistema fisico che accoglie l’applicazione;
• Quali sono i vincoli di infrastruttura che devo valutare al fine del disegno applicativo (tipologia di rete, velocità della rete, presenza di componenti esclusivamente umane, etc…);
• Qual è l’organizzazione dell’infrastruttura dal punto di vista della distribuzione dei diversi componenti applicativi (front-end, back-end, RDBMS, etc…);
• È necessario avere una distribuzione del carico (Load balancing, Pooling di risorse, etc…).
E ancora bisogna affrontare il problema dell’architettura dell’usabilità:
• Quale deve essere l’ergonomia della user interface;
• Quali sono le tipologie di dispositivi che accederanno all’applicazione (PC, PDA, Smart Phone, Web o Windows Application, etc…);
• Quali sono le periferiche di interazione con l’applicazione (solo tastiera, tastiera e mouse, touch screen, etc…);
• Sono presenti molte attività di data entry massivo;
• Sarà disponibile un servizio di help desk o gli utenti dovranno operare in stato di “isolamento operativo”
• Sono presenti particolari condizioni di interazione con le apparecchiature (uso di guanti protettivi obbligatori, ridotta accessibilità ai computer, etc…).
E ultimo, ma non ultimo, tutti gli aspetti di architettura dell’integrazione, ovvero
• Siamo di fronte ad un sistema chiuso o aperto;
• Se non è un sistema chiuso, come espone se stesso o come interagisce con altri sistemi;
• Quali sono le interazioni previste e quali le regole di servizio (SLA) che ogni sistema coinvolto deve rispettare;
• Esistono processi trans-aziendali e come devono essere coordinati tra di loro.
Queste domande, con altre, sono alla base di ciò che deve fare l’architetto.
La soluzione e la qualità
Per operare bene è necessario rispondere alle domande, a tutte le domande, con una strategia d’approccio omogenea e coerente.
Fornire soluzioni concettuali ottimali a partire dagli strumenti che il mercato propone e che siano coerenti con le scelte complessive.
Un architetto deve essere laico, le battaglie “fideistiche” su specifiche scelte di bit&byte o di “prodotto” non lo devono riguardare.
Al centro dell’attenzione dell’architetto deve rimanere l’eccellenza della soluzione, la qualità percepibile dal cliente e l’efficienza complessiva del sistema.
E tra queste prima fra tutte, nel lavoro dell’architetto del software, è la massima attenzione alla qualità percepita dal cliente.
La qualità è sempre segnata da tre punti di vista distinti: la qualità intrinseca, la qualità espressa e la qualità percepita.
Una soluzione può essere di grandissima qualità intrinseca, ma salvo il programmatore, che sviluppa l’algoritmo iper sofisticato, nessun altro è in grado di percepire questa qualità, viceversa una soluzione non particolarmente brillante dal punto di vista strettamente tecnico, può risultare estremamente performante ed efficace per l’utilizzatore del sistema.
L’architetto è spesso chiamato a compromessi tra la massima qualità intrinseca e la qualità percepita.
La sua laicità, e conseguente capacità di non innamorarsi di una soluzione, gli permette di vedere il sistema sempre con uno sguardo disincantato e lucido di chi deve primariamente fornire al cliente esattamente ciò che gli serve e ciò che lui si aspetta dall’applicazione (anche se non è automatico che questi due aspetti siano pienamente sincronizzati).
L’architetto deve guidare lo sviluppo del software attraverso i meandri e le contraddizioni di esigenze spesso contrapposte, deve avere uno sguardo complessivo e aperto.
L’architetto scrive codice
Spesso viene posta la domanda se l’architetto software possa essere anche lo sviluppatore di ciò che progetta.
Due sono gli aspetti da valutare.
L’architetto software deve conoscere molto bene il materiale che inserirà nel progetto quindi non è possibile che non conosca gli strumenti a disposizione per la realizzazione di una soluzione e tra questi i linguaggi di programmazione, gli ambienti di sviluppo, i tools, le applicazioni server e tutto quanto possa essere coinvolto nello sviluppo di una soluzione.
Altro aspetto è legato alla sua partecipazione diretta allo sviluppo del software con la scrittura di codice applicativo.
Sul primo aspetto non c’è nulla da dire, l’architetto non solo può, ma deve avere una conoscenza tutt’altro che minimale degli ambienti di sviluppo e dei relativi linguaggi.
Per quello che riguarda il coinvolgimento sullo sviluppo del software è buona cosa se l’architetto del software si astiene dal partecipare direttamente a questa attività.
Questo per una serie di motivazioni: l’architetto è il garante delle scelte che l’insieme degli attori coinvolti nella realizzazione di una applicazione devono fare.
Il suo coinvolgimento come una delle parti in gioco, tra l’altro su elementi strettamente operativi, non potrebbe che essere limitativo della libertà di visione e di scelta (a discapito della qualità fornita al cliente).
Inoltre una componente fondamentale dello sviluppo è la fantasia, l’inventiva, l’abbandono di ogni schema per trovare la soluzione giusta. Un eccellente programmatore è proprio questo: fantasia e inventiva.
Ma l’architetto deve essere anche metodo e materiali oltre che inventiva; la fantasia e l’inventiva nell’architetto è elemento di lavoro, ma non è il valore primario.
La realtà delle aziende meno grandi è che nei progetti software i diversi ruoli sono, di volta in volta, affidati alla stessa persona che li interpreta in base alle esigenze specifiche (il DBA può scrivere codice o fare test e documentazione, l’analista può scrivere codice o effettuare dei test, lo sviluppatore può occuparsi di installare l’infrastruttura di sistema, e così via).
Anche se questo è ormai metodo e/o necessità, rimane fortemente sconsigliato che l’architetto mescoli ruoli diversi.
Questo perlomeno sino a che il progetto non sia completamente definito e percorra binari condivisi e accettati.
Conclusioni
La figura dell’architetto è sicuramente una figura di riferimento centrale, ha compiti e responsabilità importanti e la sua capacità di essere interdisciplinare è fondamentale.
Architetti del software non si nasce, lo si diventa con una crescita basata sulla continua curiosità ed attenzione al mondo reale.
Si può essere dei buoni architetti o anche eccellenti architetti, ma l’unica unità di misura di questo è l’opinione degli altri e i risultati ottenuti.
È una professione che permette bellissime esperienze e grandi soddisfazioni, ma è un lavoro nel quale commettere errori, anche veniali, può produrre risultati devastanti.
Insomma una buona dose di umiltà, una grande competenza multi disciplinare, formazione continua e a 360 gradi, rigore, lucidità e laicità.
Ultima domanda prima di chiudere queste note: visto questo profilo, questo mix notevole e non facile da ottenere e mantenere nel tempo, come mai siamo così tanti a voler fare gli architetti?
posted by ilmale at
5:37 PM
Application: BeginRequest
Application: PreAuthenticateRequest
Application: AuthenticateRequest
Application: PostAuthenticateRequest
Application: PreAuthorizeRequest
Application: AuthorizeRequest
Application: PostAuthorizeRequest
Application: PreResolveRequestCache
Application: ResolveRequestCache
Application: PostResolveRequestCache
Application: PreMapRequestHandler
Page: Construct
Application: PostMapRequestHandler
Application: PreAcquireRequestState
Application: AcquireRequestState
Application: PostAcquireRequestState
Application: PreRequestHandlerExecute
Page: AddParsedSubObject
Page: CreateControlCollection
Page: AddedControl
Page: AddParsedSubObject
Page: AddedControl
Page: ResolveAdapter
Page: DeterminePostBackMode
Page: PreInit
Control: ResolveAdapter
Control: Init
Control: TrackViewState
Page: Init
Page: TrackViewState
Page: InitComplete
Page: LoadPageStateFromPersistenceMedium
Control: LoadViewState
Page: EnsureChildControls
Page: CreateChildControls
Page: PreLoad
Page: Load
Control: DataBind
Control: Load
Page: EnsureChildControls
Page: LoadComplete
Page: EnsureChildControls
Page: PreRender
Control: EnsureChildControls
Control: PreRender
Page: PreRenderComplete
Page: SaveViewState
Control: SaveViewState
Page: SaveViewState
Control: SaveViewState
Page: SavePageStateToPersistenceMedium
Page: SaveStateComplete
Page: CreateHtmlTextWriter
Page: RenderControl
Page: Render
Page: RenderChildren
Control: RenderControl
Page: VerifyRenderingInServerForm
Page: CreateHtmlTextWriter
Control: Unload
Control: Dispose
Page: Unload
Page: Dispose
Application: PostRequestHandlerExecute
Application: PreReleaseRequestState
Application: ReleaseRequestState
Application: PostReleaseRequestState
Application: PreUpdateRequestCache
Application: UpdateRequestCache
Application: PostUpdateRequestCache
Application: EndRequest
Application: PreSendRequestHeaders
Application: PreSendRequestContent
posted by ilmale at
3:16 PM
Often people, especially computer engineers, focus on the machines. They think, "By doing this, the machine will run faster. By doing this, the machine will run more effectively. By doing this, the machine will something something something.
" They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves."
Yukihiro "Matz" Matsumoto
posted by ilmale at
6:10 PM
Netical official notes blog
