This list comes handy when you are provisioning new SharePoint farms and sites.

The full list of annotations supported in EF is:

· KeyAttribute – Placed on property to specify key

· StringLengthAttribute – Placed on the property to specify string length

· MaxLengthAttribute – Placed on the property to specify maximum length

· ConcurrencyCheckAttribute - Specifies that a property participates in optimistic concurrency checks.

· RequiredAttribute – Placed on the property to specify required field

· TimestampAttribute – Placed on the property to identify timestamp field used for concurrency resolution

· ComplexTypeAttribute – Identify property as complex type

· ColumnAttribute - Placed on a property to specify the column name, ordinal & data type

· TableAttribute - Placed on a class to specify the table name and schema

· InversePropertyAttribute - Placed on a navigation property to specify the property that represents the other end of a relationship

· ForeignKeyAttribute - Placed on a navigation property to specify the property that represents the foreign key of the relationship

· DatabaseGeneratedAttribute - Placed on a property to specify how the database generates a value for the property (Identity, Computed or None)

· NotMappedAttribute - Placed on a property or class to exclude it from the database

I hope you will find this list helpful. I certainly do as I use it almost everyday.

Cheers,

When I’m team lead, I look for people who love to keep other people productive. That means handling all the productivity killers in an engineering team: hiring and firing, inter-team meetings, customer presentations, reporting up and out and sideways, planning, travel coordination, conferences, expenses… all those things which we don’t want engineers to spend much time on or have rattling around at the back of their minds. It also means caring about people, and being that gregarious and nosy type of person who knows what everyone is doing, and why, and also what’s going on outside the workplace.

An engineering lead is doing well if every single member of their team can answer these questions, all the time:

* what are my key goals, in order of importance, in this cycle?
* what are the key delivery dates, in this cycle?
* how am I doing, generally? and what is the company view of my strengths and not-so-strengths?
* how do I fit into the team, who are my counterparts, and how do I complement them?

Also, the lead is doing well if they know, for each member of their team:

* what personal stresses or other circumstances might be a distraction for them,
* what the interpersonal dynamics are between that member, and other counterparts or team members,
* what that member’s best contributions are, and strongest interests outside of the assigned goals

For the team as a whole, the lead should know

* what the team is good at, and weak at, and what their plan is to bolster what needs bolstering,
* what the cycle looks like, in terms of goals and progress against them
* what the next cycle is shaping up to look like, and how that fits with long term goals

Hope you will find these tidbits helpfull....

SharePoint Server 2010 Feature GUIDs

Principles of Good Programming

The principles of good programming are closely related to principles of good design and engineering. The following programming principles have helped me over the years become a better programmer, and I believe can help any developer become more efficient and to produce code which is easier to maintain and that has fewer defects.

1. DRY - Don’t repeat yourself - This is probably the single most fundamental tenet in programming is to avoid repetition. Many programming constructs exist solely for that purpose (e.g. loops, functions, classes, and more). As soon as you start repeating yourself (e.g. a long expression, a series of statements, same concept) create a new abstraction. http://en.wikipedia.org/wiki/Don%27t_repeat_yourself
2. Abstraction Principle - Related to DRY is the abstraction principle “Each significant piece of functionality in a program should be implemented in just one place in the source code.” http://en.wikipedia.org/wiki/Abstraction_principle_(programming)
3. KISS (Keep it simple, stupid!) - Simplicity (and avoiding complexity) should always be a key goal. Simple code takes less time to write, has fewer bugs, and is easier to modify. http://en.wikipedia.org/wiki/KISS_principle
4. Avoid Creating a YAGNI (You aren’t going to need it) - You should try not to add functionality until you need it. http://en.wikipedia.org/wiki/YAGNI
5. Do the simplest thing that could possibly work - A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design. http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html
6. Don’t make me think - This is actually the title of a book by Steve Krug on web usability that is also relevant in programming. The point is that code should be easily read and understood with a minimum of effort required. If code requires too much thinking from an observer to understand, then it can probably stand to be simplified http://www.sensible.com/dmmt.html
7. Open/Closed Principle - Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. In other words, don't write classes that people can modify, write classes that people can extend. http://en.wikipedia.org/wiki/Open_Closed_Principle
8. Write Code for the Maintainer - Almost any code that is worth writing is worth maintaining in the future, either by you or by someone else. The future you who has to maintain code often remembers as much of the code, as a complete stranger, so you might as well always write for someone else. A memorable way to remember this is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.” http://c2.com/cgi/wiki?CodeForTheMaintainer
9. Principle of least astonishment - The principle of least astonishment is usually referenced in regards to the user interface, but the same principle applies to written code. Code should surprise the reader as little as possible. The means following standard conventions, code should do what the comments and name suggest, and potentially surprising side effects should be avoided as much as possible. http://en.wikipedia.org/wiki/Principle_of_least_astonishment
10. Single Responsibility Principle - A component of code (e.g. class or function) should perform a single well defined task. http://en.wikipedia.org/wiki/Single_responsibility_principle
11. Minimize Coupling - Any section of code (code block, function, class, etc) should minimize the dependencies on other areas of code. This is achieved by using shared variables as little as possible. “Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability” http://en.wikipedia.org/wiki/Coupling_(computer_programming)
12. Maximize Cohesion - Code that has similar functionality should be found within the same component. http://en.wikipedia.org/wiki/Cohesion_(computer_science)
13. Hide Implementation Details - Hiding implementation details allows change to the implementation of a code component while minimally affecting any other modules that use that component. http://en.wikipedia.org/wiki/Information_Hiding
14. Law of Demeter - Code components should only communicate with their direct relations (e.g. classes that they inherit from, objects that they contain, objects passed by argument, etc.) http://en.wikipedia.org/wiki/Law_of_Demeter
15. Avoid Premature Optimization - Don’t even think about optimization unless your code is working, but slower than you want. Only then should you start thinking about optimizing, and then only with the aid of empirical data. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" - Donald Knuth. http://en.wikipedia.org/wiki/Program_optimization
16. Code Reuse is Good - Not very pithy, but as good a principle as any other. Reusing code improves code reliability and decrease development time. http://en.wikipedia.org/wiki/Code_reuse
17. Separation of Concerns - Different areas of functionality should be managed by distinct and minimally overlapping modules of code. http://en.wikipedia.org/wiki/Separation_of_concerns
18. Embrace Change - This is the subtitle of a book by Kent Beck, and is also considered a tenet of extreme programming and the agile methodology in general. Many other principles are based on the concept that you should expect and welcome change. In fact very old software engineering principles like minimizing coupling are related directly to the requirement of making code easier to change. Whether or not you are an extreme programming practitioner, this approach to writing code just makes sense. http://www.amazon.com/gp/product/0321278658

Executive-to-executive relationships are some of the most powerful ways to cement ties with key customers and develop them as references. C-level executives with a background in high-level consultative sales are likely to understand how to foster these relationships, but for those not accustomed to such customer interactions, here are some tips.

First, understand the customer's predominant "behavioral type."

Different people respond to relationships in different ways. If you've been paired up with a customer executive, the best way to get off on the right foot is to understand his behavioral type. It doesn't require a PhD or handing him some sort of assessment tool. Skilled sales people can size people up quickly and do so all the time. Is she a Driver? Analytical? Expressive? Amiable? Here's a useful checklist. Different types respond to different approaches and have different emotional triggers. An Expressive executive, for example, loves the spotlight and will likely be excited about getting up on stage or in the media with his success story. A Driver may be ambitious to raise his professional stature, which can guide you in developing reference opportunities that will excite him. However, he'll also want any issues he has with your delivery resolved fast.

Understand--and care about--the customer's problems

Whatever the customer's behavioral type, building strong business relationships means nurturing the emotional component, which hard-driving executives at your firm may sometimes overlook. Nothing will stifle a budding relationship more than a customer's realization that you don't really care.

Provide value

As the relationship builds, provide value from time to time. Send a link to an article or blog post you come across that intelligently addresses an issue he's dealing with. Or a recommend thoughtful book. Put him in touch with relevant people in your network. But again, be careful in your approach. Few things are more annoying than an overly eager new friend who starts sending you things that are intended to be "helpful" but that only reveal he really wasn't listening to the issues you confided to him.
Don't get bogged down in discussions about the customer's problems . .

This may seem paradoxical in light of what I just said, but demonstrating you care doesn't mean spending an hour going into the details of a problem your firm can't help him solve. That's a waste of your time and his. Demonstrating empathy doesn't require mastering details.
. . . unless the problem meets these tests:
* It's serious.
* The customer--or one of her colleagues at her firm--is personally feeling real emotional pain as a result (frustration, worry, fear, etc).
* Solving the problem would create a substantial monetary impact on the customer's business.
* And of course, it's something your firm could solve.

Build a rapid response network between your firms

As you develop critical information about your customer--their needs, frustrations, what delights them, etc--you'll want to respond rapidly and effectively. Is something frustrating them about your delivery? Fix it. Has a new need arisen that makes sense for your firm to address? Get your NPD team on it. Are they delighted with that new consulting offering you provide? Ask for a reference and then deploy your video testimonial or white paper team. A rapid response network should include executive peers from both firms, along with lower lever implementation people from both firms, together with regular communication and follow-up processes.

Ask for referrals

As you build the relationship, and particularly as your firm chalks up impressive results for the customer, ask for referrals--the most powerful lead generator of them all. "Who else at AAA Corp should I be talking to?" "Who else within your professional network (inside our outside the firm) should I get to know?"

Today, I would like to take this opportunity reiterate that SOLID principle provide great benefits to the SharePoint development.

Lets review what SOLID stands for. The acronym SOLID is derived from the following phrases/principles in English:

Single Responsibility Principle: Each class should have a unique responsibility or main feature. In other words, one class should have only one reason that justifies performing changes on its source code. One consequence of this principle is that, in general, classes should have few dependencies on other classes/types.

Open Closed Principle: A class must be open for extension but closed for modification. That is, the behavior of a class should be able to be extended without requiring modifications on its code.

Liskov Substitution Principle: Sub-types must be able to be replaced by their base types (base class or interface). This stems from the fact that the behavior of a program that works with abstractions (base classes or interfaces) should not change because a specific implementation is replaced with another one. Programs should refer to abstractions, and not to implementations. We will see later that this principle is closely related to the Dependency Injection and substitution of some classes for others providing they meet the same interface.

Interface Segregation Principle: The class interface implementers should not be obliged to implement methods that are not used. This means the class interfaces should be specific depending on who consumes them and should therefore be split into different interfaces, and no large interfaces should be created. Classes should expose separate interfaces for different clients/consumers with differing interface requirements.

Dependency Inversion Principle: Abstractions should not depend on details; the details should depend on

abstractions. Direct dependencies between classes should be replaced by abstractions (interfaces) to allow top-down designs without the need to design the lower levels first.

Other key design principles

• The component design must be highly cohesive: do not overload the components by adding mixed or non-related functionality. For example, avoid mixing data access logic with business logic belonging to the Domain model. When functionality is cohesive, we can then create assemblies with more than one component and place them in the appropriate layers of the application. This principle is therefore closely related to the "N-layer" pattern and to the „Single Responsibility Principle‟.
• Keep the cross-cutting code abstracted from the application-specific logic: the cross-cutting code refers to horizontal aspect code, such as security, operations management, logging, instrumentation, etc. The combination of this type of code with specific implementation of the application can lead to designs that, in the future, are difficult to extend and maintain. The AOP (Aspect Oriented Programming) principle is related to this.
• Separation of Concerns: dividing the application in different parts and minimizing the overlapping functionalities between such parts. The key factor is to minimize the interaction points to achieve high cohesion and low coupling. However, separating functionality in the wrong boundaries can lead
  to a high degree of coupling and complexity among the characteristics of the system.
• Don‟t Repeat Yourself (DRY): the "intention" must be specified in only one part of the system. For example, in terms of an application design, a specific functionality should be implemented in only one component; the same functionality should not be implemented in other components.
• Minimize the top-down design (Upfront Design): design only what is necessary, do not perform "over engineering" and take into account the agile YAGNI principle („You Ain‟t Gonna Need It‟).

Next time you design SharePoint project, ask yourself a question: 

Is my application design and architecture SOLID?

Recently, I successfully finished all four SharePoint 2010 exams:

• Exam 70-573: TS: Microsoft SharePoint 2010, Application Development

• Exam 70-576: PRO: Designing and Developing Microsoft SharePoint 2010 Applications

• Exam 70-667: TS: Microsoft SharePoint 2010, Configuring

• Exam 70-668: PRO: SharePoint 2010, Administrator

As a result I completed last prerequisite required to apply for entry into Microsoft Certified Master – SharePoint Server 2010.

Next, I filled the MCM program application online, provided my MCP Transcript access code and paid $125.00 application fee. Shortly after, I received confirmation message stating:

“Thank you for submitting your application. You will receive an email within 24 hours notifying you if you have passed the pre-requisite exam stage. If you have passed, you will be given access to another site to upload your documents for industry review. Your payment receipt for the application fee is attached to this email.”

Same evening l received email from Brett A. Geoffroy, Program Manager for SharePoint MCM/MCA providing me with additional information on the MCM program. He also invited me to contact him with any questions about the program.

In few days Brett called me and we spent some time going over the MCM program, about my resume and qualifications. Brett also answered many questions I had about the program and its structure. We finished our phone call with setting up date and time of my technical screening phone conference with existing SharePoint MCM’s.

About 2 weeks later time I dialed into conference call with Brett and 2 SharePoint MCM’s. For next hour I was grilled on the architecture, security and other SharePoint areas. This technical screen is designed to measure depth and width of the candidate SharePoint knowledge and the screeners definitely had deep knowledge of SharePoint technologies as you could expect from the MCM. I really enjoyed this screen, as it gave me clear idea on expected level of knowledge for the candidate. I was able to identify areas on which I will need to concentrate in my SharePoint studies.

After few days I received email from Brett and we scheduled technical screen debriefing. During debriefing I and Brett discussed the technical screen and the areas I need to concentrate on. Brett, again went over the details of the MCM-SharePoint program, cast, scheduling and planned changes. Then he finally told me that I met all of the MCM program pre-requisites and I am eligible to enroll into the MCM-SharePoint rotation and which rotation I would like to attend.

I am very excited to be part of the MCM-SharePoint Server 2010 program, but I also know that I will need to spend considerable amount of hard studying and experimentation with the SharePoint 2010 to be ready for fall or winter rotation.

Till next time….

Cheers,

Ivan

Many of you don't yet know about the TechNet Wiki, a place for IT professionals to share information about Microsoft products. You will find articles posted by Microsoft employees, MVPs, and other product experts. While we always recommend that you take a look at the SharePoint TechCenter on TechNet, the wiki is a great place to find and share solutions with others. Join today with your Windows Live ID!

Some useful links for getting started with the wiki:

• Join the Wiki Community. Begin interacting with technology professionals.
• Get to know the Wiki. Discover all of the exciting features.
• A day in the life of an article. Learn about composition, revision, and comments.
• Contribute your knowledge. Share your expertise with technology professionals worldwide.

In addition, here are a few links to get you started with SharePoint Server 2010 on the TechNet wiki:

• SharePoint Products Resources for IT Pros
• SharePoint Survival Guide
• Enterprise search