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
Sep 19, 2007
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.
Subscribe to:
Posts (Atom)
Posts
