Adobe AIR aims at enabling the development of rich desktop applications using Internet technologies - or in other words, Rich Internet Applications on the desktop. Combining the advantages of the two worlds, AIR will allow you to seamlessly combine Flash, HTML, AJAX and PDF into applications that will be installed using a Click Once install using a single install file across platforms, and then effortlessly run on different platforms using the AIR runtime engine - similar to the .NET runtime that gets downloaded for Silverlight applications. It will provide support for HTML/AJAX using an embedded browser, Flash using a Flash player, but will need to bridge to a local Acrobat PDF reader. It will provide APIs for accessing local system resources, and ideally, these APIs will be provided in such a way that your applications can work across platforms without the need to be ported for any specific one. Once installed, these applications will behave like locally installed desktop applications - including showing up in the Add/Remove Programs, and Start folders!
Pretty interesting - but I am wondering if this hotch potch of technologies will be a great idea, really! I would still bank on Silverlight...
Thursday, December 27, 2007
Tuesday, December 25, 2007
Being an Architect: Ray Ozzie
Here's an excerpt from an interview Ray Ozzie, Microsoft's Chief Software Architect, gave to the Architecture Journal. Definitely an eye opener and a must-follow-guide to all budding Architects like me!
AJ: Given your responsbilities, what does a day in the life of Microsoft’s chief software architect look like?
RO: From my vantage point, being an architect is really about pattern matching. It’s about being exposed to enough tools and techniques of the trade that over time you start to develop a toolkit of different patterns that work in different situations. This is true of software architecture and probably other types of architecture as well. Whether you build bridges or design buildings, you’re trying to apply design patterns to a given situation.
My role within Microsoft is an interesting one because there are very strong architects within the different product groups, within the different divisions of the company, and they’re doing a terrific job on their products. My role is essentially a cross-cutting one. By that I mean understanding how customers are using multiple products together, and then asking myself what patterns I see. What’s the smallest possible thing I could suggest to a product team that they could do to re-architect their product in order to minimize seams with other products? Or from a business perspective, what’s the smallest possible thing I could overlay on these products to add value for our customers, and advantage our solutions in the market.
At the very highest level, my advice to aspiring architects is, don’t jump in too
quickly. You need to do your time as a programmer to understand the different patterns that are out there, and recognize the attributes of well-architected systems, in order to raise yourself to the next level of abstraction in the solutions you’re building.
AJ: It sounds like the ability to do pattern matching really comes down to experience?
RO: Absolutely. It especially pertains to the things that nobody at the architecture level likes to think about. For example, performance characteristics, IO characteristics, reliability characteristics… You might have had experience with a system that works well given a certain level of complexity, but if used in a more dynamic environment it could be too fragile. You only learn that through experience.
AJ: I imagine that to do that you must have a wide array of knowledge across multiple technologies. Given that, and the product teams you interact with each day, how do you keep up to date?
RO: It’s really an interesting combination. The easiest and most natural thing is to just talk to people in your sphere of influence, and gain exposure to different technologies as a part of your job. But in order to be successful long term, you need to stay in touch with the trends and what’s going on externally, especially staying in touch with what customers or individual users are saying and doing.
I spend a fair amount of time reading blogs, tracking specific influencers that have very interesting voices both related to our products and completely unrelated to our products.
I go to a combination what I call ‘head’ and ‘tail’ conferences. I’ll attend a few where the known industry influencers congregate. These allow me to track major competitive issues, or at least the outward presentation of what competitors might be saying and doing. But I also enjoy the tail conferences, where you can get a closer-to-the-ground perspective on what’s really happening. I like to meet people who are just out of school, who have startups and understand the kinds of technology choices they’re making and why.
At the highest level, my advice to an aspiring architect is find the right balance of focus on internal and external trends that will give you the perspective you need.
AJ: That’s definitely great advice. Related to this, what would you say are defining characteristics of an effective software architect?
RO: The most effective architects I’ve dealt with are the ones who’ve paid their dues. These are the architects who’ve spent time in the trenches building and debugging fairly complex systems. You can learn a lot about how things work by fixing other people’s bugs. When something fails and the person has left the company, you can learn a lot by either reverse engineering or looking at the documentation. The more systems that you can learn from the inside out, the more you can develop an understanding for bad practice and good practice design patterns. As I mentioned earlier, it’s this library of patterns in your mind that will define you as an architect.
AJ: Given your responsbilities, what does a day in the life of Microsoft’s chief software architect look like?
RO: From my vantage point, being an architect is really about pattern matching. It’s about being exposed to enough tools and techniques of the trade that over time you start to develop a toolkit of different patterns that work in different situations. This is true of software architecture and probably other types of architecture as well. Whether you build bridges or design buildings, you’re trying to apply design patterns to a given situation.
My role within Microsoft is an interesting one because there are very strong architects within the different product groups, within the different divisions of the company, and they’re doing a terrific job on their products. My role is essentially a cross-cutting one. By that I mean understanding how customers are using multiple products together, and then asking myself what patterns I see. What’s the smallest possible thing I could suggest to a product team that they could do to re-architect their product in order to minimize seams with other products? Or from a business perspective, what’s the smallest possible thing I could overlay on these products to add value for our customers, and advantage our solutions in the market.
At the very highest level, my advice to aspiring architects is, don’t jump in too
quickly. You need to do your time as a programmer to understand the different patterns that are out there, and recognize the attributes of well-architected systems, in order to raise yourself to the next level of abstraction in the solutions you’re building.
AJ: It sounds like the ability to do pattern matching really comes down to experience?
RO: Absolutely. It especially pertains to the things that nobody at the architecture level likes to think about. For example, performance characteristics, IO characteristics, reliability characteristics… You might have had experience with a system that works well given a certain level of complexity, but if used in a more dynamic environment it could be too fragile. You only learn that through experience.
AJ: I imagine that to do that you must have a wide array of knowledge across multiple technologies. Given that, and the product teams you interact with each day, how do you keep up to date?
RO: It’s really an interesting combination. The easiest and most natural thing is to just talk to people in your sphere of influence, and gain exposure to different technologies as a part of your job. But in order to be successful long term, you need to stay in touch with the trends and what’s going on externally, especially staying in touch with what customers or individual users are saying and doing.
I spend a fair amount of time reading blogs, tracking specific influencers that have very interesting voices both related to our products and completely unrelated to our products.
I go to a combination what I call ‘head’ and ‘tail’ conferences. I’ll attend a few where the known industry influencers congregate. These allow me to track major competitive issues, or at least the outward presentation of what competitors might be saying and doing. But I also enjoy the tail conferences, where you can get a closer-to-the-ground perspective on what’s really happening. I like to meet people who are just out of school, who have startups and understand the kinds of technology choices they’re making and why.
At the highest level, my advice to an aspiring architect is find the right balance of focus on internal and external trends that will give you the perspective you need.
AJ: That’s definitely great advice. Related to this, what would you say are defining characteristics of an effective software architect?
RO: The most effective architects I’ve dealt with are the ones who’ve paid their dues. These are the architects who’ve spent time in the trenches building and debugging fairly complex systems. You can learn a lot about how things work by fixing other people’s bugs. When something fails and the person has left the company, you can learn a lot by either reverse engineering or looking at the documentation. The more systems that you can learn from the inside out, the more you can develop an understanding for bad practice and good practice design patterns. As I mentioned earlier, it’s this library of patterns in your mind that will define you as an architect.
Thursday, December 06, 2007
Innovation!
Progress isn't made by early risers or hard workers, but by lazy people, who find easier ways to do difficult things! Henry Ford.
Subscribe to:
Posts (Atom)
