Saturday, December 29, 2007
Friday, December 28, 2007
Happy New Year’s Resolutions for Internet Junkies:
- I will try to figure out why I *really* need 7 e-mail addresses.
- I will stop sending e-mail to my wife.
- I resolve to work with neglected children—my own.
- I will answer my snail mail with the same enthusiasm with which I answer my e-mail.
- I resolve to back up my hard drive daily...well, once a week...okay, monthly then...or maybe...
- I will spend less than one hour a day on the Internet.
- When I hear "Where do you want to go today?" I won’t reply "MS Tech Support."
- I will read the manual.
- I will think of a password other than "password".
- I will stop checking my e-mail at 3:00 in the morning.
I've got this congratulation from Dmitry Krushinsky, thanks for that!
Wednesday, December 26, 2007
Saturday, December 22, 2007
Friday, December 21, 2007
Friday, December 14, 2007
Thursday, December 13, 2007
In the article of Sten and Per Sundblad "Business Improvement Through Better Architected Software" different roles of the architect are suggested.
"Business architecture should be established and managed by a new breed of business architects rather than by the old business analysts. Software architecture should be established and managed by solution architects with a more business-oriented and a less technical background than yesterday’s application architects. Business and solution architects should work together to design and suggest improved business processes that take better advantage of technical
opportunities than the original ones did.
But still it is difficult to find a company where all these roles are performed by different people.
In the most cases the person who is responsible for project business-technical vision takes all these roles. I see the shift of roles, but all together they are the same :)
Saturday, December 01, 2007
Wednesday, November 28, 2007
This here, 5 useful communication skills:
- Make sure the person you’re talking to is ready to hear what you’re saying.
- Instead of complaining, ask for what you want in concrete, measurable terms.
- Give feedback if expectations aren’t met, even if the effort is good.
- Take responsibility to make your boundary needs clear.
- You must keep talking. That’s the only way to make progress.
Wednesday, November 21, 2007
Tuesday, November 20, 2007
Saturday, November 17, 2007
Again! Why they are constantly mixing these things: SaaS and Software+Service? Even in the channel9 video cast with Steve Swartz, Clemens Vasters and David Chappell the approaches are identified.Besides they talk about connected systems and do that in a very simple manner.
Friday, November 16, 2007
Thursday, November 15, 2007
Having read an article "Ten commandments of Steve Job" I found it interesting to share my attitude to each clause. So here they are:
- Never let people know where they stand. - Partially agree
- You don’t have to hire the best people. - Agree
- Only promote stupid people. - Disagree
- Never tell people what is expected of them. - Partially agree
- A manager should be inconsistent and unpredictable. - Unpredictable - yes, inconsistent - never!
- No praise. Ever. - Disagree
- Keep people’s spirits broken. - Disagree!
- Throw tantrums. - Disagree
- Don’t speak to employees in elevators. - Why?
- Start with the ad campaign. - Partially agree
Wednesday, November 14, 2007
A fascinating idea from Gianpaolo's blog "In a closed system, software complexity does not go away, it just changes hands"
You know that since companies are constantly at risk of losing sensitive cardholder data, which could result in fines, legal action and bad publicity, achieving compliance with the PCI DSS should be high on the agenda of companies who store, transmit or process credit card data. Furthermore, PCI DSS compliance needs to be achieved by December, 2007 – this is the deadline posed by credit card companies. Organizations that fail to comply face fines of up to $500,000 if the data is lost or stolen and risk not being allowed to handle cardholder data.
Did you know that? I did not. Think many of you too :) Beware! Keep your $500,000 !!!
Monday, November 05, 2007
1) Gather and organize both technical and business requirements
2) Envision and create a solution that meets requirements and can be implemented
3) Model the pieces of an infrastructure and their points of integration
4) Prove the feasibility of a design, the toughest thing :)
Just 4 steps. And I need to walk them over in a few days.
Sunday, November 04, 2007
Sometime it's very important to think as a customer. So what he writes:
"When planning to integrate your SaaS applications, certain things need take place. First, you need to define the information you need to integrate, what it is, who owns it, and how it's accessed. While most SaaS vendors have APIs or Web services to support integration, many of these interfaces are not well thought out or are limited in some way. Next, you need to define the interfaces and information on the enterprise applications side, answering many of the same questions. This means you should have a semantic- and interface-level understanding of the integration domain, including all systems connected, SaaS and non-SaaS."
A good case comment. It must be owned we often do things nobody particularly needs. And that's a pitty.
The article can be found here.
Friday, November 02, 2007
I found this chart at http://msdn2.microsoft.com/en-us/library/bb945098.aspx
In the article the author shows what an EA does and how his/her role relates to other architecture roles within the enterprise. A good way to represent architects in terms of breath and depth and for developers either.
Sunday, October 14, 2007
Sunday, October 07, 2007
Tuesday, September 11, 2007
Efficient Software Delivery Through Service-Delivery Platforms by Gianpaolo Carraro, Fred Chong, and Eugenio Pace
Summary: Delivering software as a service (SaaS) has gained a lot of momentum. One reason this one-to-many delivery model is attractive is that it enables new economies of scale. Yet economy of scale does not come automatically; it has to be explicitly architected into the solution. A typical architectural pattern allowing economy of scale is "single instance multi-tenancy," and many Independent Software Vendors (ISVs) offering SaaS have moved to this architecture, with various levels of success.
There is, however, another means of improving efficiency which ISVs have not adopted with the same enthusiasm: the use of an underlying Service-Delivery Platform (SDP). Adoption has been slow, mainly because service-delivery platforms optimized for line-of-business applications delivery are still in their infancy. But both existing and new actors in the hosting space are quickly building compelling capabilities. This paper explores the goals, capabilities, and motivations for adoption of SDP, and describes the technology and processes related to efficient software delivery through SDP.
In addition I have to make a note that the article is quite intelligible and makes many things related to SaaS clear. My verdict - RECOMMENDED
Tuesday, September 04, 2007
Three Characteristics of Engineering
- Mature Engineering Disciplines Provide Design Decomposition from Top to Bottom
- Mature Engineering Disciplines Use Analysis Techniques (Which Might or Might Not Be Mathematical) to Test Each Level of Design
- Mature Engineering Disciplines Have Implicit Requirements, as Well as Explicit Requirements
So it seems to me I am not an engineer, I'm a smith at most :(
Sunday, September 02, 2007
Check the Silverlight project for cool examples.
Tuesday, August 28, 2007
- Solutions Architect
Also known as: Application Architect, Software Architect, Data Architect, Integration Architect
Role: The Solutions Architect manages the design of one or more applications or services within an organization, usually within the scope of a division.
Some would argue that “Software Architect” is more applicable here. But since the design for many applications and services often transcends the creation of software – for example, in a data-heavy application or the integration of a series of applications – the term “Solution Architect” is a good fit in many cases and seems to be gaining adoption.
The Solutions Architect works with the Enterprise Architect for strategic direction (both conforming to strategy, and helping to define it).
- Infrastructure Architect
Also known as: Technology Architect, Systems Architect
Role: The Infrastructure Architect’s job includes the design of the datacenter and the deployment and maintenance of applications and services across the organization.
This role involves working with both the Solution Architect to design for scalability, reliability, manageability, performance, and security, and the Enterprise Architect, from whom he receives and contributes to strategic direction.
- Enterprise Architect
Also known as: Strategic Architect, Chief Architect, Business Architect
Role: The Enterprise Architect is concerned about the strategic vision of application and services within the organization. He or she is responsible in part for strategic direction and ensuring all applications comply with internal policies, and may be in charge of setting the direction for methodologies, tools and frameworks used.
Many people believe that Strategic Architect is a more fitting title here because there can be a disconnect between Enterprise Architect (the role) and Enterprise Architecture (when used to describe architecture for an Enterprise), but the term Enterprise Architect seems to have built up some momentum over the past few years, and is generally more accepted.
The classification was taken from here.
Monday, August 27, 2007
"A system architect is responsible for creating or selecting the most appropriate architecture for a system (or systems), such that it suits the business needs, satisfies user requirements, and achieves the desired results under given constraints."
That brought me back my study in the uni with all those sophisticated definitions :)
Besides, read this if you want to know what does it take to be an architect.
Saturday, August 18, 2007
Saturday, July 21, 2007
Monday, July 16, 2007
I believe the shifts were caused by the whole community so let's be regarded as a merit! :)
I expect the changes will happen not only within MS but there and everywhere!!
P.S. The full article may be read here
Tuesday, June 26, 2007
Thursday, June 07, 2007
Microsoft Code Name “Acropolis” is a set of components and tools intended to make it easier for developers to build and manage modular, business focused, client applications for Microsoft Windows on the .NET Framework.
Seems developers will be out of job soon :(
Download it here: http://www.microsoft.com/downloads/details.aspx?familyid=72386ce5-f206-4d5c-ab09-413b5f31f935&displaylang=en&tm
Sunday, June 03, 2007
Why? MS people apparently tell us the same and they came to a conclusion that there is a misunderstanding of a security problems importance on the CxO level and on the customer's level at the same time. I think CxO level is quite adequate. They raise money. Poor customers....
The final pasage is well turned: "A final note to help illustrate my point – for those of you that are old enough to remember, there was an old TV commercial for Fram Oil Filters that showed a mechanic working on the tear down of some old beater. At the end of the commercial, the mechanic turns to the camera and says, "You can pay me now, or you can pay me later..." "
The whole article can be found here: http://blogs.msdn.com/sdl/archive/2007/05/31/oil-change-or-culture-change.aspx
Wednesday, May 09, 2007
The document is a set of privacy guidelines for developing software products and services that are based on Microsoft internal guidelines and their experience incorporating privacy into the development process.
Included in This Document:
Basic Concepts and Definitions
Scenario 1: Transferring PII to and from the Customer’s System
Scenario 2: Storing PII on the Customer’s System
Scenario 3: Transferring Anonymous Data from the Customer’s System
Scenario 4: Installing Software on a Customer’s System
Scenario 5: Deploying a Website
Scenario 6: Storing and Processing User Data at the Company
Scenario 7: Transferring User Data Outside the Company
Scenario 8: Interacting with Children
Scenario 9: Server Deployment
You can download the copy from here.
Sunday, May 06, 2007
Friday, May 04, 2007
Wednesday, April 25, 2007
<%@ Page Async="true" ...
Jeff Prosise's in his article explains that this tells ASP.NET to implement IHttpAsyncHandler in the page. Next, you should call the new Page.AddOnPreRenderCompleteAsync method early in the page's lifetime (for example, in Page_Load) to register a Begin method and an End method, as shown in the following code:
AddOnPreRenderCompleteAsync (new BeginEventHandler(MyBeginMethod), new EndEventHandler (MyEndMethod)
These two methods will be called after PreRender Event. To catch the idea look at the picture below.
Taken from http://msdn.microsoft.com/msdnmag/issues/05/10/WickedCode/
Async processing benefits are depicted in http://msdn.microsoft.com/msdnmag/issues/07/03/WickedCode/
Saturday, March 17, 2007
In the article of Michael Howard "A Look Inside the Security Development Lifecycle at Microsoft" it is shown how to solve security problems on the grounds of development phases.
Special thanks to Oliver Szimmetat from Microsoft for the helpful references.
Friday, March 02, 2007
And this is only the start. What's going to be further? Perhaps some of us will have portable "tape-recorders" that will tape every step we do, every emotion, every smell and so on.....
These thoughts make me prick up ears.
Friday, February 23, 2007
Tuesday, February 13, 2007
On the 13th of February canadian D-Wave company is going to present its Quantum Computer. As they say this machine should have unrestricted computational power: 65536 threads concurrently. This will certainly increase computation power although cryptoanalyst will get a key to the all existing cryptoalgorithms.
Friday, February 02, 2007
Monday, January 29, 2007
Sunday, January 28, 2007
Saturday, January 27, 2007
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.
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
Thursday, January 18, 2007
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.
Wednesday, January 10, 2007
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.:
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.