Monday, January 29, 2007
Sunday, January 28, 2007
Not about IT but All about Life
Love Story (1970) by Arthur Hiller has made an impression upon me. I know, I know it's hard to say it is brand new story or maybe the actors performed wonderful but the idea "Love means never having to say you're sorry" is hard to argue about.
Enjoy http://www.imdb.com/title/tt0066011/
Enjoy http://www.imdb.com/title/tt0066011/
Saturday, January 27, 2007
Think forward
"Think forward. Think researchchannel." - the word I've read on the ResearchChannel web site.
Aside the ad, I'm utterly support these words. And the site content seems to me very interesting and well done.
In 1991, Microsoft Corp. became the first software company to create its own computer science research organization.
Nowadays Microsoft Research (MSR) consists of many research labs, balancing an open academic model with an effective process for transferring its research to product development teams.
Aside the ad, I'm utterly support these words. And the site content seems to me very interesting and well done.
In 1991, Microsoft Corp. became the first software company to create its own computer science research organization.
Nowadays Microsoft Research (MSR) consists of many research labs, balancing an open academic model with an effective process for transferring its research to product development teams. I found on-line lectures and regret having not much time to watch all of them :(
Efficiency, scripting, strong typing, productivity... F# ?
Today I've watched an interview from the Niner's (Channel9) where Microsoft Guru talked about programming languages and mentioned above all F#.
On the Microsoft site
I read that F# is an ML language truly at home on .NET with smooth interop with other .NET languages.
For example, C# and F# can call each other directly. This means that F# has immediate access to all the .NET Framework APIs, including, for example, WinForms and DirectX. Similarly, libraries developed in F# are available for use from other .NET languages.
F# is the first ML language where all the types and values in an ML program can be accessed from some significant other languages (e.g., C#) in a predictable and friendly way.
F# was the first released .NET language to produce Generic IL, and the compiler was designed partly with this language in mind. The compiler can also produce (non-generic) v1.0 or v1.1 .NET binaries.
F# supports features that are often missing from ML implementations such as Unicode strings, dynamic linking, preemptive multithreading and SMP machine support
This is the only language which provides a combination of scripted/functional/imperative/object-oriented programming language. That is a basis for many practical scientific, engineering and web-based programming tasks.
F# comes with F# for Visual Studio, an extension to Visual Studio 2003 and Visual Studio 2005 that supports features such as an integrated build/debug environment, graphical debugging, interactive syntax highlighting, parsing and typechecking, IntelliSense, CodeSense, MethodTips and a simple project system.
On the Microsoft site
I read that F# is an ML language truly at home on .NET with smooth interop with other .NET languages.For example, C# and F# can call each other directly. This means that F# has immediate access to all the .NET Framework APIs, including, for example, WinForms and DirectX. Similarly, libraries developed in F# are available for use from other .NET languages.
F# is the first ML language where all the types and values in an ML program can be accessed from some significant other languages (e.g., C#) in a predictable and friendly way.
F# was the first released .NET language to produce Generic IL, and the compiler was designed partly with this language in mind. The compiler can also produce (non-generic) v1.0 or v1.1 .NET binaries.
F# supports features that are often missing from ML implementations such as Unicode strings, dynamic linking, preemptive multithreading and SMP machine support
This is the only language which provides a combination of scripted/functional/imperative/object-oriented programming language. That is a basis for many practical scientific, engineering and web-based programming tasks.
F# comes with F# for Visual Studio, an extension to Visual Studio 2003 and Visual Studio 2005 that supports features such as an integrated build/debug environment, graphical debugging, interactive syntax highlighting, parsing and typechecking, IntelliSense, CodeSense, MethodTips and a simple project system.
Saturday, January 20, 2007
Experiencing Orcas
Recently I've installed Orcas December 2006 Community Preview and got a chance to test the environment. Without going deeply into all new features I must admit the system is resource-intensive thus on my virtual machine it works evidently hardly. Intelli Sense is also a striking thing cause it does not always work. But nevertheless it is only community preview so let's be patient and wait for a full release version I believe would be more high-speed and responsive.
Thursday, January 18, 2007
Test Your Project for Agility.
Top Ten Signs That Your Project Is Just Pretending to Be Agile
10. The project plan has just been published by the project manager and it shows the first release happening 18 months after the start of the project. If this happens, you know the project isn't Agile. In Agile projects, the focus is on the planning activity, not the resulting plan. Planning causes the team to make decisions and set priorities so that something valuable can be released in a few months, and first release after 10 months practically dooms a project to failure.
9.The project manager is talking about the deliverables that the systems analysts will hand off to the application architects. Warning: Waterfall ahead! The next thing you'll see is the architects handing off yet more deliverables to the designers.
8.The systems analysts and application architects are proud of the fact that they didn't write any code on their last project. Bragging about not having written any code is a clear sign that the analysts and architects think that writing the code is a trivial and easy part of the project. With that viewpoint, it's only a small step toward valuing working software less than they value their documentation, a clear contradiction of the manifesto. Whenever any member of an "agile" team brags about being "above" another team member's activities, the team is just pretending; it has forgotten that the real goal is to collaboratively deliver working software.
7.The project is structured so that the programmers and testers are definitely at the lower end of the food chain. Agile projects start coding and testing much earlier than more traditional approaches, typically within weeks of starting the project. Putting the programmers and testers at the end of a long food chain makes it impossible for the project to be Agile.
6.The systems analysts keep trying to get users to sign off on the requirements document. Freezing the requirements might be a good idea in some circumstances, but the Agile approach is to collaborate with the customer to deliver what's needed when the software is released, not what was thought to be necessary when the contract was signed.
5.The development team complains whenever a change request manages to sneak its way through the change-control process. An instant giveaway. Agile projects expect and embrace change.
4.You're more than two months into the project and the project team still hasn't demonstrated any useful functionality to the users. PowerPoint slides or screen mockups don't count—have the users seen a real part of the application yet? Agile projects let users get their hands on the software really early, so that the users can let the rest of the team know what to do to improve the software.
3.The project leads consider the documentation to be more important than communication. This happens when the project is producing a copious paper trail, recording all decisions made to ensure requirements traceability—but in spite of that, nobody on the team seems to understand what's really going on. This isn't to say that documentation is bad—just that it has to be kept in perspective. If information is important enough to be written down in project documentation, it's probably important enough to get the attention of a professional technical writer. If making the documentation easy to read isn't a priority, you can draw your own conclusions about the project, but it definitely isn't Agile.
2.Testing and quality assurance are not an integral, respected part of the development team. All Agile approaches rely on early testing and validation for feedback about the quality of the software. As such, the testing and quality assurance activities are recognized as a vital part of the development process that have to start on day 1 of the project. Deferring testing or quality assurance activities until later in the project is a sure sign that the process is not Agile.
1.Tasks are assigned to individuals who take their work away to a quiet place and treat it as a solo assignment. Whenever "team members" are always seeking a quiet place to work, or wear headphones to block out the distractions from the rest of the "team," you can bet that the team leads don't understand collaborative development. If they don't understand the basics of collaborative development, you can be certain that the project is definitely not Agile, regardless of the posters that might be up on the wall.
BUT Remeber! Agile Is Not a Silver Bullet.
Source here
10. The project plan has just been published by the project manager and it shows the first release happening 18 months after the start of the project. If this happens, you know the project isn't Agile. In Agile projects, the focus is on the planning activity, not the resulting plan. Planning causes the team to make decisions and set priorities so that something valuable can be released in a few months, and first release after 10 months practically dooms a project to failure.
9.The project manager is talking about the deliverables that the systems analysts will hand off to the application architects. Warning: Waterfall ahead! The next thing you'll see is the architects handing off yet more deliverables to the designers.
8.The systems analysts and application architects are proud of the fact that they didn't write any code on their last project. Bragging about not having written any code is a clear sign that the analysts and architects think that writing the code is a trivial and easy part of the project. With that viewpoint, it's only a small step toward valuing working software less than they value their documentation, a clear contradiction of the manifesto. Whenever any member of an "agile" team brags about being "above" another team member's activities, the team is just pretending; it has forgotten that the real goal is to collaboratively deliver working software.
7.The project is structured so that the programmers and testers are definitely at the lower end of the food chain. Agile projects start coding and testing much earlier than more traditional approaches, typically within weeks of starting the project. Putting the programmers and testers at the end of a long food chain makes it impossible for the project to be Agile.
6.The systems analysts keep trying to get users to sign off on the requirements document. Freezing the requirements might be a good idea in some circumstances, but the Agile approach is to collaborate with the customer to deliver what's needed when the software is released, not what was thought to be necessary when the contract was signed.
5.The development team complains whenever a change request manages to sneak its way through the change-control process. An instant giveaway. Agile projects expect and embrace change.
4.You're more than two months into the project and the project team still hasn't demonstrated any useful functionality to the users. PowerPoint slides or screen mockups don't count—have the users seen a real part of the application yet? Agile projects let users get their hands on the software really early, so that the users can let the rest of the team know what to do to improve the software.
3.The project leads consider the documentation to be more important than communication. This happens when the project is producing a copious paper trail, recording all decisions made to ensure requirements traceability—but in spite of that, nobody on the team seems to understand what's really going on. This isn't to say that documentation is bad—just that it has to be kept in perspective. If information is important enough to be written down in project documentation, it's probably important enough to get the attention of a professional technical writer. If making the documentation easy to read isn't a priority, you can draw your own conclusions about the project, but it definitely isn't Agile.
2.Testing and quality assurance are not an integral, respected part of the development team. All Agile approaches rely on early testing and validation for feedback about the quality of the software. As such, the testing and quality assurance activities are recognized as a vital part of the development process that have to start on day 1 of the project. Deferring testing or quality assurance activities until later in the project is a sure sign that the process is not Agile.
1.Tasks are assigned to individuals who take their work away to a quiet place and treat it as a solo assignment. Whenever "team members" are always seeking a quiet place to work, or wear headphones to block out the distractions from the rest of the "team," you can bet that the team leads don't understand collaborative development. If they don't understand the basics of collaborative development, you can be certain that the project is definitely not Agile, regardless of the posters that might be up on the wall.
BUT Remeber! Agile Is Not a Silver Bullet.
Source here
Wednesday, January 10, 2007
Recent articles about .net
"Simple and Efficient Multi-threading with Blocking Queues" by Garry Barclay discusses multi-threading, and how it relates to queues; show you a simple implementation of the Airline check-In queue that can be very helpful for your own multi-threaded applications, and provide some guidelines for analyzing and tuning the performance of the queue.
Original article can be found here.
Ahmed El Malt tells us that .Net 2.0 introduced new assembly-level attribute , InternalsVisibleTo attribute which is defined in the System.Runtime.CompilerServices namespace . This attribute allows you to expose internal types and methods to another specified assembly. Ex.:
[assembly: InternalsVisibleTo("MyFriendAssembly")]
So any class in the assemblies MyFriendAssembly will be able to use MyInternalClass and call its public or internal members. In addition, any subclass in the MyFriendAssembly assembly will be able to access members marked as protected internal.
Original article can be found here.
Ahmed El Malt tells us that .Net 2.0 introduced new assembly-level attribute , InternalsVisibleTo attribute which is defined in the System.Runtime.CompilerServices namespace . This attribute allows you to expose internal types and methods to another specified assembly. Ex.:
[assembly: InternalsVisibleTo("MyFriendAssembly")]
So any class in the assemblies MyFriendAssembly will be able to use MyInternalClass and call its public or internal members. In addition, any subclass in the MyFriendAssembly assembly will be able to access members marked as protected internal.
Subscribe to:
Posts (Atom)