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 ;)
Saturday, August 20, 2011
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
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
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...
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?
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):
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.
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)"
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:
(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.
Wednesday, August 4, 2010
Measuring performance from the user's point of view
Check this javascript, boomerang.
In their own words:
"boomerang is a piece of javascript that you add to your web pages, where it measures the performance of your website from your end user's point of view. It has the ability to send this data back to your server for further analysis. With boomerang, you find out exactly how fast your users think your site is."
Sounds like a great tool for performance check.
In their own words:
"boomerang is a piece of javascript that you add to your web pages, where it measures the performance of your website from your end user's point of view. It has the ability to send this data back to your server for further analysis. With boomerang, you find out exactly how fast your users think your site is."
Sounds like a great tool for performance check.
Tuesday, June 29, 2010
SharePoint 2010 + ADFS 2.0
A client wants us to provide them with an intranet site, in which several organizations are able to work together, but without adding any trust between their independent AD's.
The solution was to use ADFS 2.0. There is a lot of information going on, but I found it quite hard to find exactly what I wanted, in an easy and fast manner.
Here it is for you:
http://blogs.pointbridge.com/Blogs/nielsen_travis/Pages/Post.aspx?_ID=33
The solution was to use ADFS 2.0. There is a lot of information going on, but I found it quite hard to find exactly what I wanted, in an easy and fast manner.
Here it is for you:
http://blogs.pointbridge.com/Blogs/nielsen_travis/Pages/Post.aspx?_ID=33
Friday, June 25, 2010
Send custom Response on Page_Load
Ever had a scenario where you'd like to stop the current Response and give an entirely different one?
From ASP.Net 2.0++, you'll have to not only do a Response.End(), but before that a HttpContext.Current.ApplicationInstance.CompleteRequest();
Why? Because Response.End() no longer stops the page processing, so if you, for instance, are sending a file to the response stream, for some reason, it will get the page's HTML in the end of the file's contents.
Special thanks to a post by Rick Strahl, here.
From ASP.Net 2.0++, you'll have to not only do a Response.End(), but before that a HttpContext.Current.ApplicationInstance.CompleteRequest();
Why? Because Response.End() no longer stops the page processing, so if you, for instance, are sending a file to the response stream, for some reason, it will get the page's HTML in the end of the file's contents.
Special thanks to a post by Rick Strahl, here.
Subscribe to:
Posts (Atom)