Saturday, August 27, 2011

Warming up your farm

Every SharePoint developer knows how slow the first load of a page is for users, after resetting the IIS or just recycling the application pool.

There is an option to prevent the delay in the first load: warmup scripts. There are some scripts using stsadm, both for the 2007 and 2010 platforms. In this last version, PowerShell scripts are now also available.

Check one of them here, by Martin Laukkanen.

Thursday, August 25, 2011

Time estimation using PERT

Although there certainly are more complex and structured ways of estimating time, there is a rather simple method to estimate time that has proven interesting to me in many scenarios: PERT.

Basically, you'll have to do 3 estimations for each task: optimistic (O), most likely (M) and pessimistic (P).

These estimations are obviously dependent on how you evaluate the hardness of a task and on the people (or profile) you believe will perform them. One of the most important steps here, is defining as much sub-tasks as possible. Be as granular as possible, so that nothing is forgotten or wrongly evaluated.

After doing your set of estimations for each task/sub-task, you should apply this formula to get the expected time (TE):

TE = (O + 4M + P) ÷ 6

Also,one of the most important things in time estimations, is to keep track of your own estimations and the time they really took. Nothing like a reality check to improve your estimations. One of the aspects that should be taken into account is the person who performed the task and their level of seniority.

Monday, August 22, 2011

SharePoint 2010 CSS Reference Chart

If you ever had some challenges with the design and default CSS of SharePoint, you probably know who Heather Solomon is. Considered by most as the biggest SharePoint branding expert, she released recently the 2010 version of the SharePoint CSS Reference Chart.

If you are struggling with the SharePoint design, check this out, here.

Distributed cache platform with Windows Server AppFabric

Just run into an interesting post by Wictor Wilén, on the use of an extension to Windows Server called Windows Server AppFabric.

Every web project needs to take into account performance and one of the tools we have to improve it is caching. In a farm, we have multiple servers managing their own cache, leading to possibly different results in performance. Also, there is no sharing of resources among different applications, since caching is made in the process level.

This framework allows a wider definition of the caching policies, along with some interesting options, such as the use of dedicated servers for this task and not being restarted in each application pool recycle.

See the article here, with some hands-on instructions on how to set the environment and use the framework.

Saturday, August 20, 2011

Re-branding - done

I am no designer. But I wanted a clean layout for the blog. And no complications.
This was the result, using only the tools provided by the Blogger platform - no HTML editing whatsoever.

Feels better ;)

Friday, August 19, 2011

Code Reviewing - do you do it?

My personal experience is solely based on the Portuguese standard. We, as a nation, tend to be more relaxed about planning and procedures. Well, not all of us, and definitely not all of the companies also, but certainly a lot.

Portuguese rely and brag on their ability to quickly solve problems in real time, as they appear. It is something we call "desenrascar" and can not be easily translated to a word in English. It is what it is: find a quick (and very often suboptimal) solution for a problem.

But...aren't we talking about Code Reviewing? Of course. The introduction is just to say that it is very usual to make it work and then fix performance problems as they come along. Every project has unit testing, whether very explicitly well defined or not, throughout the development phase, but most will leave performance tests for later. And when you find problems in that phase, your work to correct them will certainly be hard.

What can you gain from Code Reviewing and how can you do it? If you have a nightly build or continuous integration process, you should integrate the basics there. Most of the times, you will find that there are already some tools to do what you need automatically (in SharePoint, the most basic piece will be the SPDisposeCheck). You should also include some performance metrics here. They can help your early and correct detection of problems.

In terms of architecture and best practices, you and your co-workers should always keep a thinking mind in place. Don't just code, think about what that code means and what it will do. Don't just implement. If you believe there is a better solution, talk it through with who made the system's architecture. It will help become a better and more complete developer. If you are an architect, you probably already know you should always try to improve your way of solving the problems and see how others nail it.

Where did this all came from? This great article in NBSP, My Top 10 sanity checks when performing SharePoint code review, by Stephane Eyskens. If you are into SharePoint, read it, even if you are aware of these issues. Always good to review and see different points of view

Thursday, August 18, 2011

SQL Server performance

Something that appeared as a central point of discussion among same colleagues: are views in SQL Server materialized?
By default, no. If you want to materialize views, to increase performance, you should look for indexed views.
It is almost unnecessary to say when to use them: if you have some data being pulled very frequently from a subset of tables joined by some logic, with few updates. You will need more disk space, but the performance will certainly increase.

Some reading links on the subject:
Creating an Indexed View in SQL Server 2005 and 2008
Chapter 14 — Improving SQL Server Performance

Re-branding

Soon I will be making a full re-brand on this blog - as soon as I have the time (and will). Each day that passes, I'm enjoying more the way things have been evolving worldwide, in this matter: simple and clean pages, with great lettering to provide a good experience while reading the contents.

Nowadays I fell this layout is too cluttered and some of the experiences I have used this for, have now reached their final destiny! And I have been feeling quite like writing...

SharePoint as a platform, not only a solution

Great article, from someone I had the pleasure of seeing in a live presentation (here in Lisbon): Dan Holmes on Lessons Learned from Enterprise SharePoint Adoption Trends.

To sum things up, I totally agree with him: nowadays, SharePoint should be used as a platform to centralize the communication and workspace between collaborators. No matter how many systems you may rely on for your daily activities, they should be easily accessible in one place. A place where you can add value, by helping everyone do a better and more informed job. Where one can easily find help on any subject, either from documents, processes or people.

In my company, we have been helping others in doing it - and with great success. My latest SharePoint 2010 project was actually used as the first Microsoft Portugal Case Study on Intranets built using SPS2010. It was in a lawyer firm and, besides a great environment to work in, everything went smooth and with everyone heading the same (and right) way! Isn't it great when clients take the full potential of what you can offer?

Tuesday, August 16, 2011

Continuous integration (automated builds) for SharePoint 2010

Great set of articles being build by Chris O'Brien (once again), Kirk Evans and Mike Morton (Microsoft).

First important thing to notice: when to really consider using automated builds (quoting Chris O'Brien):

  • "Development-oriented – perhaps with more than, say, 3 Visual Studio projects
  • Multiple developers
  • Fairly long-running (e.g. > 2-3 months; to give the team a chance to implement CI alongside the actual deliverables)"
Most projects you are involved in will probably meet these requirements, which means, "YES, I need it!".

Read the articles already released: first part by Chris O'Brien on the reasons to do it and the second by Mike Morton regarding the installation of TFS.

From my point of view, it is a great investment that will pay off in the end of the project, with a more robust, streamlined and responsible development strategy. It is definitely true that doing it with a SharePoint project is a much more challenging process that with a plain .NET development, but not doing it will most certainly lead to a worse final result. Keep that in mind, and don't be lazy!

Something that has been on my mind for the last days, that I will pursue with further investigation, is developing all the SharePoint objects using PowerShell scripts. This is a usual practice for SQL developers, so why not make it usual in SharePoint dev? It ensures that all developers can have an updated version of your portal in their own machine/dev environment and that you can, at every point in time, check what went wrong or quickly reset a specific build to see if an erratic behavior was already present.

Monday, August 15, 2011

Some reading notes...on the Management Part of Projects

How much time should you spend on requirement gathering? 30%.
(read article here)

Interesting comment about a book written in 1975, stating (event then!) that the average should be:

1/3 - Planning
1/6 - Coding
1/4 - Component Test and Early System Test
1/4 - System Test


Also, from the same author (Chris Wright - http://www.sharepointblog.co.uk/), interesting thoughts about taking ownership of a project (read article here).
I also believe this is a very important question everyone should continuously address in their own projects, no matter the specific role you may have. In the Portuguese companies/projects I have worked in, there is a slight difference. The "consultant" job is usually done by someone that will also lead the technical team. With that in mind, I believe this is the guy that should "own" the project, having the PM as a backup for the though decisions.