Soren put together the core of Ayande's JAOO talk here. Nice to read and worth looking.
http://www.publicvoid.dk/JAOO2007WritingDomainSpecificLanguagesInBooByOrenEini.aspx
Boo is something on which i want to spend some time now!....
Sep 27, 2007
Ruby ProdCasts- I want to listen to it!...
I want to listen what John Lam and Scott Bellware shares.
http://www.rubiverse.com/
This is only for me!......
http://www.rubiverse.com/
This is only for me!......
Sep 26, 2007
Agile Bibliography Wiki
George Dinwiddie announces the Agile Bibliography Wiki to track readings on the subject of agile developement.
http://biblio.gdinwiddie.com/biblio/FrontPage
Enjoy reading......
http://biblio.gdinwiddie.com/biblio/FrontPage
Enjoy reading......
Sep 25, 2007
Architectural patterns
Intension is to test my Blog!... What if one crazy fellow started testing in the Prodution enviornment itself!..... ( That is not a part of Agile methedology right??)
Read some basics!... (Thanks WIKI)
Architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.
Even though an architectural pattern conveys an image of a system, it is not an architecture as such. An architectural pattern is rather a concept that captures essential elements of a software architecture. Countless different architectures may implement the same pattern and thereby share the same characteristics. Furthermore, patterns are often defined as something "strictly described and commonly available". For example, layered architecture is a call-and-return style, when it defines an overall style to interact. When it is strictly described and commonly available, it is a pattern.
One of the most important aspects of architectural patterns is that they embody different quality attributes. For example, some patterns represent solutions to performance problems and others can be used successfully in high-availability systems. In the early design phase, a software architect makes a choice of which architectural pattern(s) best provide the system's desired qualities.
Read some basics!... (Thanks WIKI)
Architectural patterns are software patterns that offer well-established solutions to architectural problems in software engineering. An architectural pattern expresses a fundamental structural organization schema for a software system, which consists of subsystems, their responsibilities and interrelations. In comparison to design patterns, architectural patterns are larger in scale.
Even though an architectural pattern conveys an image of a system, it is not an architecture as such. An architectural pattern is rather a concept that captures essential elements of a software architecture. Countless different architectures may implement the same pattern and thereby share the same characteristics. Furthermore, patterns are often defined as something "strictly described and commonly available". For example, layered architecture is a call-and-return style, when it defines an overall style to interact. When it is strictly described and commonly available, it is a pattern.
One of the most important aspects of architectural patterns is that they embody different quality attributes. For example, some patterns represent solutions to performance problems and others can be used successfully in high-availability systems. In the early design phase, a software architect makes a choice of which architectural pattern(s) best provide the system's desired qualities.
OR Mappers and NHibernate : Overview
Hi All,
"As we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."
These prophetic words were put forth by Frederick Brooks' in his now legendary paper, No Silver Bullet, in 1986. Heeding Brooks' words to a tee, it wasn't until more than a decade later, in 1997, that the software world was presented with a hint of an upcoming silver bullet in the form of NeXT's Enterprise Object Framework...one of the first object-relational mappers (ORM). Although not regularly conspicuously stated – often to avoid being seen as a heretic of software dogma – it is commonly accepted by many that ORM technologies, when used correctly, are, in fact, a silver bullet for software development. With the maturation of NHibernate, the ORM silver bullet has been formally introduced to the world of .NET.
The most common dissenters of ORM technologies, in general, are developers using Microsoft technologies. (As I've placed myself squarely into this realm for the past decade or so, I feel quite comfortable bringing us up first!) There seems to be an unwritten rule that "if it wasn't invented by Microsoft, then wait until Microsoft puts out the right way to do it." Stepping up to the plate, Microsoft intends to do just that with "LINQ to Entities" in the upcoming C# 3.0. (Yes, officially discard the use of "ObjectSpaces" and "DLINQ.") Developers may continue to wait for this technology or, alternatively, start realizing the benefits of ORM immediately. To be fair, the not-invented-by-Microsoft toolset for .NET developers used to be sparse but has been steadily growing since the advent of .NET. Circa 2004, the "not created by the mothership" toolset of open source tools finally began to reach a respectable level of maturity and should be seriously considered for any .NET endeavor. (And since, statistically, the majority of software projects fail, it sounds like the consideration of an expanded toolset is certainly warranted.) The impending introduction of LINQ certainly brings great benefits to flexible querying. Fortunately, LINQ is not exclusive to Microsoft data-access layers and LINQ for NHibernate is already well underway by Ayende Rahien.
Other dissenters of these technologies suggest that ORMs kill application performance and only provide a significant improvement to productivity in the initial stages of development. Furthermore, the argument continues, is that the use of an ORM becomes a serious detriment to project success only later in the project, when issues of performance and maintainability begin to have a more noticeable effect. Three obvious retorts come to mind in response to these protests.
First and foremost, in support of ORMs, using a framework such as NHibernate increases your performance as a developer. If you can spend 90% less time (yes, I said "90% less time") on developing data access code, then quality time can be spent improving the domain model and tuning performance – assuming it becomes necessary. Furthermore, leveraging a simple profiling tool goes a long way towards implicating the 5% of code that's causing 95% of the performance bottleneck. And in the cases in which the data access layer is the bottleneck, simple adjustments can usually be made to reap substantial improvements. Incidentally, this is no different than when not using an ORM. (Be sure to check out Peter Weissbrod's introductory article to profiling NHibernate applications.) And in the very few situations in which the ORM framework is the bottleneck and can't be adjusted for improvement, it's trivially simple to bypass the ORM altogether if the data access layer has been properly abstracted.
Secondly, NHibernate, specifically, provides an incredible amount of control over all aspects of data-loading behavior. This has positive effects on developer productivity, application scalability, and application stability. Caching is certainly available – but this is readily available in non-ORM solutions as well. Other out-of-the-box features include lazy loading, support for inheritance, declaration of immutable classes, loading of read-only properties, support for generics, stored procedures, blah blah blah. The point is that all these powerful features have been proven in real-world scenarios and, therefore, have removed many hours of developing, debugging and tweaking a custom data access layer. (And if you really feel the need to get into the code, that's just fine since NHibernate's an open source project.)
Finally, I would argue that those who feel that ORMs like NHibernate become maintenance headaches later in a project are working with a coding architecture that would inhibit the maintenance of any data access layer. Just because I've suggested that NHibernate is a silver bullet doesn't imply that it eliminates the need for proper application design. With the proper amount of judicious, architectural forethought, NHibernate is quite possibly the most maintainable solution for tying a .NET application to a database.
Needless to say, NHibernate, like other ORM tools, has alleviated the maintenance of thousands of lines of code and stored procedures, thus allowing developers to focus more attention on the core of a project: its domain model and business logic. Even if you automatically generate your ADO.NET data-access layer using a tool such as CodeSmith or LLBLGen Pro, NHibernate provides the flexibility in decoupling your domain model from your relational model. Your database should be an "implementation detail" that is defined to support your domain model, not the other way around. The remainder of this article focuses on describing best practices for integrating NHibernate into ASP.NET using well established design patterns and "lessons learned from the field".
This is just copied from Billy McCafferty's article about NHibernate Best practices .Thanks Bill. The complete contents can be found at http://www.codeproject.com/aspnet/NHibernateBestPractices.asp
"As we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."
These prophetic words were put forth by Frederick Brooks' in his now legendary paper, No Silver Bullet, in 1986. Heeding Brooks' words to a tee, it wasn't until more than a decade later, in 1997, that the software world was presented with a hint of an upcoming silver bullet in the form of NeXT's Enterprise Object Framework...one of the first object-relational mappers (ORM). Although not regularly conspicuously stated – often to avoid being seen as a heretic of software dogma – it is commonly accepted by many that ORM technologies, when used correctly, are, in fact, a silver bullet for software development. With the maturation of NHibernate, the ORM silver bullet has been formally introduced to the world of .NET.
The most common dissenters of ORM technologies, in general, are developers using Microsoft technologies. (As I've placed myself squarely into this realm for the past decade or so, I feel quite comfortable bringing us up first!) There seems to be an unwritten rule that "if it wasn't invented by Microsoft, then wait until Microsoft puts out the right way to do it." Stepping up to the plate, Microsoft intends to do just that with "LINQ to Entities" in the upcoming C# 3.0. (Yes, officially discard the use of "ObjectSpaces" and "DLINQ.") Developers may continue to wait for this technology or, alternatively, start realizing the benefits of ORM immediately. To be fair, the not-invented-by-Microsoft toolset for .NET developers used to be sparse but has been steadily growing since the advent of .NET. Circa 2004, the "not created by the mothership" toolset of open source tools finally began to reach a respectable level of maturity and should be seriously considered for any .NET endeavor. (And since, statistically, the majority of software projects fail, it sounds like the consideration of an expanded toolset is certainly warranted.) The impending introduction of LINQ certainly brings great benefits to flexible querying. Fortunately, LINQ is not exclusive to Microsoft data-access layers and LINQ for NHibernate is already well underway by Ayende Rahien.
Other dissenters of these technologies suggest that ORMs kill application performance and only provide a significant improvement to productivity in the initial stages of development. Furthermore, the argument continues, is that the use of an ORM becomes a serious detriment to project success only later in the project, when issues of performance and maintainability begin to have a more noticeable effect. Three obvious retorts come to mind in response to these protests.
First and foremost, in support of ORMs, using a framework such as NHibernate increases your performance as a developer. If you can spend 90% less time (yes, I said "90% less time") on developing data access code, then quality time can be spent improving the domain model and tuning performance – assuming it becomes necessary. Furthermore, leveraging a simple profiling tool goes a long way towards implicating the 5% of code that's causing 95% of the performance bottleneck. And in the cases in which the data access layer is the bottleneck, simple adjustments can usually be made to reap substantial improvements. Incidentally, this is no different than when not using an ORM. (Be sure to check out Peter Weissbrod's introductory article to profiling NHibernate applications.) And in the very few situations in which the ORM framework is the bottleneck and can't be adjusted for improvement, it's trivially simple to bypass the ORM altogether if the data access layer has been properly abstracted.
Secondly, NHibernate, specifically, provides an incredible amount of control over all aspects of data-loading behavior. This has positive effects on developer productivity, application scalability, and application stability. Caching is certainly available – but this is readily available in non-ORM solutions as well. Other out-of-the-box features include lazy loading, support for inheritance, declaration of immutable classes, loading of read-only properties, support for generics, stored procedures, blah blah blah. The point is that all these powerful features have been proven in real-world scenarios and, therefore, have removed many hours of developing, debugging and tweaking a custom data access layer. (And if you really feel the need to get into the code, that's just fine since NHibernate's an open source project.)
Finally, I would argue that those who feel that ORMs like NHibernate become maintenance headaches later in a project are working with a coding architecture that would inhibit the maintenance of any data access layer. Just because I've suggested that NHibernate is a silver bullet doesn't imply that it eliminates the need for proper application design. With the proper amount of judicious, architectural forethought, NHibernate is quite possibly the most maintainable solution for tying a .NET application to a database.
Needless to say, NHibernate, like other ORM tools, has alleviated the maintenance of thousands of lines of code and stored procedures, thus allowing developers to focus more attention on the core of a project: its domain model and business logic. Even if you automatically generate your ADO.NET data-access layer using a tool such as CodeSmith or LLBLGen Pro, NHibernate provides the flexibility in decoupling your domain model from your relational model. Your database should be an "implementation detail" that is defined to support your domain model, not the other way around. The remainder of this article focuses on describing best practices for integrating NHibernate into ASP.NET using well established design patterns and "lessons learned from the field".
This is just copied from Billy McCafferty's article about NHibernate Best practices .Thanks Bill. The complete contents can be found at http://www.codeproject.com/aspnet/NHibernateBestPractices.asp
Sep 19, 2007
My Left hand is too fast!.....
All,
Siju Paul pointed out some spelling mistakes in one of my recent blog entries.
I never ever review my blog entires (Never used to review my code also!...). It is good /encouraging to know that people reading /reviewing these entires.
I thought of telling about one of the biggest issues that I am facing now.
My left hand is too fast nowadays!..... (Or is it in the otherway around ?) So my "have" is "ahev" now. "Some"thing is getting as "osem"thing and so on!....
My 'is' is 'si' now!.....
Anyway Thanks goes to Microsoft for the grt "Intellisence " baby!...It is keeping me out of troubles ( In rare cases, it is really taking me in too!...)
oHep I acn ifx this osno!... ( I can fix this soon)
Unni
Siju Paul pointed out some spelling mistakes in one of my recent blog entries.
I never ever review my blog entires (Never used to review my code also!...). It is good /encouraging to know that people reading /reviewing these entires.
I thought of telling about one of the biggest issues that I am facing now.
My left hand is too fast nowadays!..... (Or is it in the otherway around ?) So my "have" is "ahev" now. "Some"thing is getting as "osem"thing and so on!....
My 'is' is 'si' now!.....
Anyway Thanks goes to Microsoft for the grt "Intellisence " baby!...It is keeping me out of troubles ( In rare cases, it is really taking me in too!...)
oHep I acn ifx this osno!... ( I can fix this soon)
Unni
MSDN Magazine for Oct.2007
Friends,
The October 2007 issue of MSDN Magazine is now available online at http://msdn.microsoft.com/msdnmag/issues/07/10/default.aspx.
Enjoy reading.
The October 2007 issue of MSDN Magazine is now available online at http://msdn.microsoft.com/msdnmag/issues/07/10/default.aspx.
Enjoy reading.
Agile Manifesto for "Life"Process- Expect Contributions
Friends,
Whenever i fail to execute something (in Technical/Non Technical) in my life , i always used to go back and think.... why this happend (now) and how can i avoid such things again in future.
Today i am in bit of "Philo" mood and want to create a set Principles (Agile ) for some real life scenarios!...
Here's the Agile Manifesto for your reference. (I want to learn and expertise this everyday- Its like "Geetha".
Expecting same set of principles to overcome/resolve/execute(?) the realtime enterprise applciation(or legacy?) called Life!..
Expect your views/inputs to form the Agile Life Manifesto for "Life" process. Show your creativity!.....
Principles behind the Agile Manifesto
Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Whenever i fail to execute something (in Technical/Non Technical) in my life , i always used to go back and think.... why this happend (now) and how can i avoid such things again in future.
Today i am in bit of "Philo" mood and want to create a set Principles (Agile ) for some real life scenarios!...
Here's the Agile Manifesto for your reference. (I want to learn and expertise this everyday- Its like "Geetha".
Expecting same set of principles to overcome/resolve/execute(?) the realtime enterprise applciation(or legacy?) called Life!..
Expect your views/inputs to form the Agile Life Manifesto for "Life" process. Show your creativity!.....
Principles behind the Agile Manifesto
Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
LINQ and DL impacts
LINQ is really changing the way we used Data access layers in the past.
I found a series of articles in Kris Vandermotten's blog.
I am yet to go on top of this. So keeping the links for me too...
http://krisvandermotten.wordpress.com/2006/11/19/creating-a-data-access-layer-with-linq-to-sql-part-1/
http://krisvandermotten.wordpress.com/2006/11/30/creating-a-data-access-layer-with-linq-to-sql-part-2/
Enjoy the reading.. Break the rules...
I found a series of articles in Kris Vandermotten's blog.
I am yet to go on top of this. So keeping the links for me too...
http://krisvandermotten.wordpress.com/2006/11/19/creating-a-data-access-layer-with-linq-to-sql-part-1/
http://krisvandermotten.wordpress.com/2006/11/30/creating-a-data-access-layer-with-linq-to-sql-part-2/
Enjoy the reading.. Break the rules...
My update
I thought of finish my personal web site work by today, But failed to do so. It will eb coming live with all features by end of this week.
Want to include TBlogger and Some Album management features too..
Want to include TBlogger and Some Album management features too..
Common Domain Specific Language
Last two days in my work place was spent only for discussions . It raised one thoguht in my mind, : If the business requirements are not clear, complex, and if both business anlalists and designers /developers struggle to fix "things"(requirements that not clear enough to express in any language!...) related to domain/business areas, what are the best possible ways in which an agile team can overcome these ?
1. Can we (Techies) all talk UbiquitousLanguage ?
2. How much effecient it is in specific domain areas? It it really amtured enough?
Let me put it for you in a better terms (Expert way)
Problem:
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of the software project). And even the same person uses different language in speech and in writing, so that the most incisive impression of the domain often emerges in a transient form that is never captured in the code or even in writing.Translation blunts communication and makes knowledge crunching anemic.Yet none of these dialects can be a common language because none serves all needs.
Solution:
Use the model as a backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing and especially speech.Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods and modules to conform to the new model. Resolve confusion over terms in conversaion, in just the way we come to agree on the meaning of ordinary words.
1. Can we (Techies) all talk UbiquitousLanguage ?
2. How much effecient it is in specific domain areas? It it really amtured enough?
Let me put it for you in a better terms (Expert way)
Problem:
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of the software project). And even the same person uses different language in speech and in writing, so that the most incisive impression of the domain often emerges in a transient form that is never captured in the code or even in writing.Translation blunts communication and makes knowledge crunching anemic.Yet none of these dialects can be a common language because none serves all needs.
Solution:
Use the model as a backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing and especially speech.Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods and modules to conform to the new model. Resolve confusion over terms in conversaion, in just the way we come to agree on the meaning of ordinary words.
Sep 18, 2007
UbiquitousLanguage
I want to do some research on "UbiquitousLanguage " and share some basics about it here for my friends who are still wondering what is this "Thing".
A concept from DomainDrivenDesign. The aim of which is to establish a common consistent language structured around the problem domain that can be shared by the business users of the system and the developers.
Ubiquitous language is important because it reduces the common communication problems that occur between software users and software producers. It rapidly becomes the lingua franca of any software project that uses this technique, with users as well as software developers talking in a more consistent, more acurate way about the problem at hand, and sometimes even finding more consistent ways to talk about their own business.
http://domaindrivendesign.org/discussion/messageboardarchive/UbiquitousLanguage.html
A concept from DomainDrivenDesign. The aim of which is to establish a common consistent language structured around the problem domain that can be shared by the business users of the system and the developers.
Ubiquitous language is important because it reduces the common communication problems that occur between software users and software producers. It rapidly becomes the lingua franca of any software project that uses this technique, with users as well as software developers talking in a more consistent, more acurate way about the problem at hand, and sometimes even finding more consistent ways to talk about their own business.
http://domaindrivendesign.org/discussion/messageboardarchive/UbiquitousLanguage.html
Sep 16, 2007
www.agilemechanic.com
Alpha version hosted now.( IS there any concept of Alpha version in case of personal sites? haha)
This is just an image. Not a working copy.
Real site will be launched with in couple of days.
wait for it...
This is just an image. Not a working copy.
Real site will be launched with in couple of days.
wait for it...
Sep 13, 2007
Today's work
I am on top of "something" today, want to make it as simple as possible. Will make that happens in couple of days!... Wait for it.
Atleast i am waiting for it to happen.....
Atleast i am waiting for it to happen.....
Sep 12, 2007
SpadeWorx...
I was too happy to get a call from Anil Pagar ( My previous facilitator/co-ordinator (on HP Meadia Smart Server /Windows Home server ) and offcourse a great friend too) from Newyork. He is working hard (it's 24/7) on his new dream SpadeWorx, http://www.spadeworx.com/index.html along with couple of his friends ( Mandar and Jitendra).
I am too happy to see people walking stright towards his/her dreams!......through their hardwork and commitment.
SpadeWorx specializes in Software Product Lifecycle Services and Application Lifecycle Services.
I wish him and team all the success and may in future, we all again work together for a common goal!....
Friends , Give Anil , Mandar and Team a big hand!...
I am too happy to see people walking stright towards his/her dreams!......through their hardwork and commitment.
SpadeWorx specializes in Software Product Lifecycle Services and Application Lifecycle Services.
I wish him and team all the success and may in future, we all again work together for a common goal!....
Friends , Give Anil , Mandar and Team a big hand!...
http://dannorth.net/introducing-bdd : Back to basics
Folks,
We all are talking a lot about BDD nowadays .
Those who really want to clear the basics/revisit, here goes a nice article from one of the best .http://dannorth.net/introducing-bdd
Enjoy reading.
We all are talking a lot about BDD nowadays .
Those who really want to clear the basics/revisit, here goes a nice article from one of the best .http://dannorth.net/introducing-bdd
Enjoy reading.
Last thing to do : Delete!...
I was playing with my blogger settings and end up in deleting some of my old posts!... Missed it...
Memories of 9/11: ( from CNN.COM)
Relatives of September 11 victims bowed their heads in silence Tuesday to mark the moments exactly six years earlier when hijacked planes crashed into the World Trade Center, the Pentagon and a Pennsylvania field. The dreary skies created a grim backdrop, and a sharp contrast to the clear blue of that morning in 2001.
Construction equipment now fills the vast city block where the World Trade Center once stood. Work under way for four new towers forced the ceremony to be moved away from the twin towers' footprints and into a nearby park for the first time.
2,974 victims were killed by the September 11 attacks: 2,750 connected to the World Trade Center, 40 in Pennsylvania and 184 at the Pentagon. Those numbers do not include the 19 hijackers.
Time... will help us to resolve/overcome everything. May god bless us all.
Relatives of September 11 victims bowed their heads in silence Tuesday to mark the moments exactly six years earlier when hijacked planes crashed into the World Trade Center, the Pentagon and a Pennsylvania field. The dreary skies created a grim backdrop, and a sharp contrast to the clear blue of that morning in 2001.
Construction equipment now fills the vast city block where the World Trade Center once stood. Work under way for four new towers forced the ceremony to be moved away from the twin towers' footprints and into a nearby park for the first time.
2,974 victims were killed by the September 11 attacks: 2,750 connected to the World Trade Center, 40 in Pennsylvania and 184 at the Pentagon. Those numbers do not include the 19 hijackers.
Time... will help us to resolve/overcome everything. May god bless us all.
How Open Spaces Works !.. ALT.NET Conf.
Hi Friends,See.....Whoever shows up is the right group. Whatever happens is the only thing that could have. Whenever it starts is the right time. When it's over, it's over.An Open Space conference's agenda is decided upon by the conference participants during the opening of the event.You can identify an issue relating to the theme of the conference for which you have a genuine passion and for which you will take real responsibility.Think of powerful ideas that really grab you to the point that you will take personal responsibility to make sure that something gets done at the conference.You may lead sessions, you may participate as an attendee, you may take responsibility for capturing proceedings, or you may just hang out in the halls and talk with interesting people.Be prepared to be surprised.So am I.........
ALT.NET Conf
Hi Freinds,Yet another chance for me to interact , learn and share Technology!... To be Agile... From Oct 5 - Oct 7 in Austin, TX.The ALT.NET Conference applies Open Space Technology to create a dialog between people who are trying to learn ALT.NET practices and people who are working toward communicating the practices.Thrilled.... so see/experience the cream of Microsoft Tech. Open world!....Will share mroe on that soon.
Welcome
Hi All,In the past, used different blogs, published contents in different places, and in the middle, as usual, left all of them behind. Now, again, back in action.I want to keep this as a technology blog, but same time, want to share ideas, crazy thoughts and this will serve as a knowledgebase too.
Subscribe to:
Posts (Atom)
Posts
