Architettura
Questa categoria è aggregata anche su
GUISA
E’ da quando ho iniziato a fare i corsi sulla versione Architect che spiegavo che i DSL non erano alternativi a UML, il “problema” è che Visio EA prima e Visio Pro dopo potevano non essere sufficienti ad utenti più “evoluti”. Le cose andranno a cambiare, ma per quanto mi riguarda le cose più importanti del post sono: il DSL Toolkit non viene abbandonato, anzi, i nuovi designer UML sono basati su di esso. UML verrà usato per la modellazione “logica” e i DSL per quella...
Ieri ho letto il nuovo post del mio idolo intitolato Crash dummies: Resilience e la risposta del sempre grande Larry Osterman intitolata Resilience is not necessarily a good thing. Al solito i post di Eric, anzi di I.M.Wright (suo alterego...) sono molto provocativi e spesso portati agli estremi. La risposta di Larry invece è molto più tecnica, ed entra nei meccanismi della gestione delle eccezioni, del principio fail fast, etc... Secondo me come al solito la verità sta nel mezzo. Il primo post cerca di mettersi dalla parte dell'utente, il secondo dalla parte di chi sviluppa e deve considerare problematiche...
Secondo me Leon sbaglia su una serie di aspetti, ma sotto sotto vedo anche qualcosa di concreto, soprattutto come vengono presentati certi tool da "certe" persone... Voi che ne pensate? I could be completely wrong about this -- but I'm just going to make some bold and disparaging remarks about the whole existence of workflow software and see what happens. Leggete il resto alla Fonte: Workflow software: I'm calling the bluff.
Stavolta sulla D (Durability) dell'acrostico ACID. Bella la conclusione: Basically, big, complex, and distributed system are big, complex, and distributed. We can't get perfect behavior out of them. Something needs to be durable only if I, the partner, am still around to notice the need for it to durable! Fonte: Durability Is in the Eye of the Beholder
Giusto perchè quelle di due TechEd da finire di vedere non bastavano... le trovate qui: http://msdn.microsoft.com/architecture/saf Fonte: Strategic Architect Forum 2007
Ci sono una serie di motivi... è sempre molto interessante capire il perchè di certe scelte architetturali. If you have gotten a chance to try an early build of SQL Server Reporting 2008 Reporting Services, you know that one of the changes in the product is the removal of the Internet Information Services (IIS) dependency. I have gotten some questions about the motivation behind this change so I thought I would give you a quick peek behind the decision. The first reason we moved away from IIS is for better configuration. IIS was built several years ago to do...
Bellissimo post di David Chappel sulla differenza tra Microsoft (che può permettersi livelli di innovazione molto più spinti dato che controlla liguaggi, piattaforma e tool) e i "consorzi di aziende", come ad esempio quelli che hanno creato tutti gli standard alla base di Java (JSR xxxx, J2EE, etc...) e che ora non riescono più a trovare lo stesso livello di accordo che trovavano nel passato (si veda la difficoltà di SCA). Il post termina così, ma leggetelo perchè ne vale la pena. We're headed for a world where the big vendors are forced to strike out on their...
Spettacolare post su tutti i "cattivi" dello sviluppo software... attenzione che il 'Big "A" Architect" non ha nulla a che fare con l'Architetto con la A maiuscola dei miei post precedenti... sono solo omonimi... Leggete (e ridete... forse...) alla Fonte: Software Super Villains
David Chappel è una delle persone più chiare e brillanti che conosco. Microsoft gli ha chiesto di fare un whitepaper sui vari aspetti e i vari prodotti utilizzati per affrontare "il problema dell'Identità" Identity is an inescapable aspect of distributed applications. The .NET world provides several technologies that developers can use in this area, but figuring out what each one does and how they fit together can be challenging. ...Available here, the technologies it describes include ADFS, Windows Cardspace, and several more.Handling identity well should be a fundamental competence for anybody who creates .NET applications. The goal of this...
Quelli di ALT.NET lo vorrebbero così: Do. Guidance on core concepts and principles like OOP, separation of concerns, layering, etc Guidance on good software engineering and design practices, code quality, TDD, DDD, BDD, code smells, CI Patterns / Anti-patterns - GOF / Fowler, etc (Don't make up new ones) Tutorials / examples Be Neutral / Pragmatic Trusted advisor on different tools, techniques and methods i.e. Stored Procs vs Dynamic SQL Existing OS solutions (NHibernate, Log4Net, etc) Be Critical including of community efforts Advocate community endeavors Engage with...
Un post molto bello di Dare Obasanjo (papà di RSS Bandit) su Consistenza vs Disponibilità nei sistemi distribuiti. Quali scelte si possono fare, e quali sono le loro implicazioni implementative e architetturali. Leggetelo tutto alla Fonte: When Databases Lie: Consistency vs. Availability in Distributed Systems
State scrivendo il Notepad 27.0? Allora potete "forse" ignorare questo post. Voi usereste un sistema INSICURO ma con tutte queste ALTRE caratteristiche architetturali? Scalabile: immaginate un PayPal dove i soldi al posto di arrivare a voi vengano distratti da altri... oppure Amazon, scalabilissimo. ma i vostri libri/mp3/lavatrici vengono inviati ad altri.... Veloce: immaginate le risposte di Google che arrivano in un lampo ma portano tutte a siti contenenti malware causa "manipolazione del DB... Affidabile: immaginate un sistema 24X7X365, magari con 5 o 6 "nove" di affidabilità ma che poi...
Attenzione... è un post lungo, provocatorio e scritto di getto... quindi per favore... non massacratemi! Rileggendo il post di Sam, mi è venuta voglia di parlare di quella che chiamo 'la diversità fra "architetti" e "Architetti"' ovvero, chi si crede "architetto" e non ha mai realizzato un sistema "enterprise" e chi fa l'"Architetto" e realizza effettivamente sistemi "enterprise", dove per enterprise intendo sistemi "grossi", con decine, centinaia o migliaia di sottosistemi distribuiti, e dove non si sta tanto a discutere di "persistance ignorance", di "IPOCO" o di "POCO", di contrapposizione tra NHibernate e LINQ/EF, di ASP.NET vs MonoRail,...
Post bellissimo. Trovo spesso architetti rimasti a Classic ASP, VB6 e COM, oppure a .NET 1.1, remoting e ASMX. Il mondo è cambiato, e spesso non basta andare alle conferenze per tenersi aggiornati. Bisogna provarle sulla propria pelle le cose, verificarne soprattutto i limiti, altrimenti è dura poterne parlare con consapevolezza. This has been said over and over again, but as long as it keeps happening it just has to be said again. A very common career path in IT "promotes" a coder over the years...
Ho sempre pensato ai Design Pattern come a degli esempi di Design, non come un "linguaggio" o peggio... Per fortuna non sono il solo. Come non quotare, soprattutto l'ultima frase. ...CUT...I've always been skeptical of using the patterns as a shared language. They shouldn't be treated like a classification system. They should be used as examples of good design principles to apply where appropriate to other code. If you can understand why the patterns are useful, you'll be able to create them without memorizing them. You'll have code that is flexible, but not overly complex. Every programmer should read the...
Al di la delle cose sotto NDA, finalmente arriva qualche notizia in più sul futuro di Visual Studio Team Edition for Software Architects: Team Architect Power Tools Currently planned scenarios: View Class Library projects on the AD (Note: projects = Visual Studio Class Library projects) View references to Class Library projects as connections on the AD Create Class Library projects from the AD Create references to Class Library projects from the AD Synchronize properties between Class Library projects and their representative applications on the AD (Notice the properties in the grid e.g. Class Namespace, Language, Assembly Name etc.)...
Una delle fonti dell'ambiguità (figura dell'architetto che si fonde con quella del PM) era MSF 3 dove la figura dell'architetto era addirittura un tutt'uno con quella del Project Manager. Visto che MSF "forgiava" generazioni di persone di MS e MCS, il danno era notevole... Per fortuna oggi (MSF 4 e successivi...) prevedono una figura a se stante molto vicina al mondo del developer e abbastanza lontana dal PM. Giusto per riprendere i post di Andrea e Dino.
Oggi ho fatto il turista (poi con calma posterò qualche foto), ma domani 20 marzo ci sarà la data pisana del tour "Ingegneria del software: dai requisiti all'architettura". Vi aspetto!!!
Ho scelto un tema molto particolare: Software Architecture: oltre il design L'architettura non coinvolge solo requisiti funzionali, analisi, design, implementazione e testing. L'architettura va oltre e si deve occupare anche di tutti i requisiti non funzionali che determinano il vero successo di una soluzione software: manutenibilità, aggiornabilità, logging, licensing, usabilità, installazione, upgrade, etc... In questo Webcast vedremo come le scelte in questi campi impattano sull'architettura del sistema e come è possibile realizzare soluzioni che ne tengano conto. Speaker: Lorenzo Barbieri •Partecipa al Webcast - 20 febbraio ore 14.30 Secondo me è un argomento che va affrontato prima o...
No, non c'entra nulla la Festa della Donna, parlo dell'evento Costruire insieme il futuro: una piattaforma per la nuova era che ci sarà nella sede della Microsoft a Segrate. 7 sessioni tecniche, SQL Server, Biztalk, OBA, WCF, SOA, VSTS, Software Factories, User Experience, e tanti altri argomenti, rendono l'8 Marzo una giornata "speciale" e intensa, dedicata ad architetti di soluzioni, project manager e responsabili dello sviluppo applicativo. Vi consiglio di non perderla, dall'inizio alla fine (soprattutto la fine... , visto che ci sarò anch'io... ). Maggiori informazioni possono essere trovate sul sito: http://www.microsoft.com/italy/msdn/risorsemsdn/eventi/application.mspx
Full Architettura Archive