Here is a short code snippet which calls a javascript when you click a custom button in sharepoint. You should register the custom javascript through Page.ClientScript.
//Load the custom button
ToolBarButton printButton = (ToolBarButton)Page.LoadControl("~/_controltemplates/ToolBarButton.ascx");
printButton.ImageUrl = "~/layout/image/print.png";
//Here is where the magic happens
printButton.NavigateUrl = "javascript:PrintPage()";
ToolBar toolBar = (ToolBar)Page.LoadControl("~/_controltemplates/ToolBar.ascx");
toolBar.Buttons.Controls.Add(printButton);
Wednesday, August 26, 2009
Friday, August 21, 2009
Symptoms of Rotting Design
There are four primary symptoms that tell us that our designs are rotting. They are not
orthogonal, but are related to each other in ways that will become obvious. they are:
rigidity, fragility, immobility, and viscosity.
Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multiweek marathon of change in module after module as the engineers chase the thread of the change through the application.
When software behaves this way, managers fear to allow engineers to fix non-critical
problems. This reluctance derives from the fact that they don’t know, with any reliability, when the engineers will be finished. If the managers turn the engineers loose on such problems, they may disappear for long periods of time. The software design begins to take on some characteristics of a roach motel -- engineers check in, but they don’t check out.
When the manager’s fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.
Fragility. Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.
As the fragility becomes worse, the probability of breakage increases with time,
asymptotically approaching 1. Such software is impossible to maintain. Every fix
makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost.
Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
Viscosity of environment comes about when the development environment is slow
and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optiimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.
These four symptoms are the tell-tale signs of poor architecture. Any application that exhibits them is suffering from a design that is rotting from the inside out. But what causes that rot to take place?
Source: Robert C. Martin (http://www.objectmentor.com/)
How can we detect sofware rot before or while it is occuring? Under the motto "To prevent is better than to cure".
The problem is that software roth rarely shows on the short term. I like to compare it to building a house... you build the basement and you realise its not level but level enough for now since your scope is quite limited. When you start building the ground floor you notice that it the problem is becoming more eminent, if after a while you construct more and more floors you will notice that your apartment block will eventually collapse but by then its too late to do something about it.
Everybody knows this but how can we prevent this? I have seen this occur over and over again due to short term quick and dirty hacks and solutions because developers do nor succeed in managing expectations. The only thing you can be certain about in software is change! "It works for now" is imo the beginning of the end.
How can we prevent this? By applying the SOLID principles:
orthogonal, but are related to each other in ways that will become obvious. they are:
rigidity, fragility, immobility, and viscosity.
Rigidity. Rigidity is the tendency for software to be difficult to change, even in simple ways. Every change causes a cascade of subsequent changes in dependent modules. What begins as a simple two day change to one module grows into a multiweek marathon of change in module after module as the engineers chase the thread of the change through the application.
When software behaves this way, managers fear to allow engineers to fix non-critical
problems. This reluctance derives from the fact that they don’t know, with any reliability, when the engineers will be finished. If the managers turn the engineers loose on such problems, they may disappear for long periods of time. The software design begins to take on some characteristics of a roach motel -- engineers check in, but they don’t check out.
When the manager’s fears become so acute that they refuse to allow changes to software, official rigidity sets in. Thus, what starts as a design deficiency, winds up being adverse management policy.
Fragility. Closely related to rigidity is fragility. Fragility is the tendency of the software to break in many places every time it is changed. Often the breakage occurs in areas that have no conceptual relationship with the area that was changed. Such errors fill the hearts of managers with foreboding. Every time they authorize a fix, they fear that the software will break in some unexpected way.
As the fragility becomes worse, the probability of breakage increases with time,
asymptotically approaching 1. Such software is impossible to maintain. Every fix
makes it worse, introducing more problems than are solved. Such software causes managers and customers to suspect that the developers have lost control of their software. Distrust reigns, and credibility is lost.
Immobility. Immobility is the inability to reuse software from other projects or from parts of the same project. It often happens that one engineer will discover that he needs a module that is similar to one that another engineer wrote. However, it also often happens that the module in question has too much baggage that it depends upon. After much work, the engineers discover that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate. And so the software is simply rewritten instead of reused.
Viscosity. Viscosity comes in two forms: viscosity of the design, and viscosity of the environment. When faced with a change, engineers usually find more than one way to make the change. Some of the ways preserve the design, others do not (i.e. they are hacks.) When the design preserving methods are harder to employ than the hacks, then the viscosity of the design is high. It is easy to do the wrong thing, but hard to do the right thing.
Viscosity of environment comes about when the development environment is slow
and inefficient. For example, if compile times are very long, engineers will be tempted to make changes that don’t force large recompiles, even though those changes are not optiimal from a design point of view. If the source code control system requires hours to check in just a few files, then engineers will be tempted to make changes that require as few check-ins as possible, regardless of whether the design is preserved.
These four symptoms are the tell-tale signs of poor architecture. Any application that exhibits them is suffering from a design that is rotting from the inside out. But what causes that rot to take place?
Source: Robert C. Martin (http://www.objectmentor.com/)
How can we detect sofware rot before or while it is occuring? Under the motto "To prevent is better than to cure".
The problem is that software roth rarely shows on the short term. I like to compare it to building a house... you build the basement and you realise its not level but level enough for now since your scope is quite limited. When you start building the ground floor you notice that it the problem is becoming more eminent, if after a while you construct more and more floors you will notice that your apartment block will eventually collapse but by then its too late to do something about it.
Everybody knows this but how can we prevent this? I have seen this occur over and over again due to short term quick and dirty hacks and solutions because developers do nor succeed in managing expectations. The only thing you can be certain about in software is change! "It works for now" is imo the beginning of the end.
How can we prevent this? By applying the SOLID principles:
- SRP: Single Reponsibility Principle
- OCP: Open Closed Principle
- LSP: Liskov Substitution Principle
- ISP: Integration Segragation Principle
- DIP: Dependency Inversion Principle
For more information on this I would recommend Robert C. Martin's Agile Principles, Patterns and Practices in C#
Monday, August 17, 2009
Adding custom properties to Webparts in Sharepoint 2007
Apparently the syntax changed in MOSS 2007 to add custom properties to your web part in.
Code below:
Code below:
[WebBrowsable(true)]
[WebDisplayName("Connection string:")]
[SPWebCategoryName("Data")]
[WebPartStorage(Storage.Shared)]
[WebDescription("Connectionstring")]
[Personalizable(PersonalizationScope.Shared)]
public string ConnectionString { get; set; }
Tuesday, February 24, 2009
Team Build: Setting up workspaces
One of the errors you might encounter whilst using team build is the following:
The guide here below will help you to avoid these. But you should also keep in mind not to make your folder structure to complex or too deep. You can group your projects in your solution using solution folders which are not reflected in your physical project location.
Working Directory Build Agent
Set the working Directory for the Build Agent to a path that is not to long (e.g. C:\BuildWorkSpace\$(BuildDefinitionPath). Be aware to add the $(BuildDefinitionPath) variable in order for every build to be stored in a unique location.
Note: this will be replacing the $(SourceDir) variable. (see below)
The specified path, file name, or both are too long. The fully qualified file
name must be less than 260 characters, and the directory name must be less than
248 characters.
The guide here below will help you to avoid these. But you should also keep in mind not to make your folder structure to complex or too deep. You can group your projects in your solution using solution folders which are not reflected in your physical project location.
Working Directory Build Agent
Set the working Directory for the Build Agent to a path that is not to long (e.g. C:\BuildWorkSpace\$(BuildDefinitionPath). Be aware to add the $(BuildDefinitionPath) variable in order for every build to be stored in a unique location.
Note: this will be replacing the $(SourceDir) variable. (see below)
Source Control Folder
Set the source control folder correctly to the folder containing the solution file.
Tuesday, January 13, 2009
Team Build: Strong naming assemblies and Team Build
This article provides a great Walkthrough for using strongly named assemblies and Team Build in combination with Automated Unit Testing.
http://ozgrant.com/2008/03/13/strong-name-your-assemblies-with-team-build-using-a-private-key/
One additional problem I came across though is when you are running x64 make sure you disable the strong name verification as wel in x64 and x86 consoles!
sn -Vr *,7f668b9f3b05cdd1
http://ozgrant.com/2008/03/13/strong-name-your-assemblies-with-team-build-using-a-private-key/
One additional problem I came across though is when you are running x64 make sure you disable the strong name verification as wel in x64 and x86 consoles!
sn -Vr *,7f668b9f3b05cdd1
Team Build: Enabling Code Coverage without using a test list
Monday, January 12, 2009
Team Build and Referenced Assemblies
This session I am going to give some tip how you should reference shared assemblies.
I am currently building an application that uses several things of Enterprise Library and RhinoMocks for unit testing. Now these references have to be made to fixed locations but this can impose problems when building from different machines (think build agents differebt developer machine setups).
What I did was on my build agent I shared the build folder and mapped a networkdrive to it (in my case s:\). then I created a structure like this:
Enltlib\latest\ to which I copied the complete bin directory from entlib. The big advantages is that if you decide to upgrade later you just rename the folder to v4.1 and create a new latest folder where you copy the latest binaries to. Like this everybody will always be referencing the latest binaries without having to redo all their references in their projects
The advantages of this approach is that its completely independent of your machine setup. And if you have to work offline from your TFS once in a while you just make sure you check out the latest version of your BuildStore share the drive on your local machine and map it to the same network drive and your projects will continue to build without having to redirect the references all the time.
I am currently building an application that uses several things of Enterprise Library and RhinoMocks for unit testing. Now these references have to be made to fixed locations but this can impose problems when building from different machines (think build agents differebt developer machine setups).
What I did was on my build agent I shared the build folder and mapped a networkdrive to it (in my case s:\). then I created a structure like this:
Enltlib\latest\ to which I copied the complete bin directory from entlib. The big advantages is that if you decide to upgrade later you just rename the folder to v4.1 and create a new latest folder where you copy the latest binaries to. Like this everybody will always be referencing the latest binaries without having to redo all their references in their projects
The advantages of this approach is that its completely independent of your machine setup. And if you have to work offline from your TFS once in a while you just make sure you check out the latest version of your BuildStore share the drive on your local machine and map it to the same network drive and your projects will continue to build without having to redirect the references all the time.
Wednesday, December 31, 2008
XP And new years resolutions
At the verge on a new year people tend to have new years resolutions and things like that mine is blog more :p amongst others. So here we go.
I recently started reading Ron Jeffries Extreme Programming Adventures in C# (http://www.amazon.com/Extreme-Programming-Adventures-DV-Microsoft-Professional/dp/0735619492). Since quite a little more then a year I Agile Development Methodologies caught my eye. Recently I am starting to dig deeper in TDD and XP. In this series of posts I will let you follow me on my journey.
I recently started reading Ron Jeffries Extreme Programming Adventures in C# (http://www.amazon.com/Extreme-Programming-Adventures-DV-Microsoft-Professional/dp/0735619492). Since quite a little more then a year I Agile Development Methodologies caught my eye. Recently I am starting to dig deeper in TDD and XP. In this series of posts I will let you follow me on my journey.
Monday, December 01, 2008
Team Foundation Server 2008 SP1 with SQL 2008
I installed TFS 2008 with sql server 2008 and when I opened Team Explorer the Reports node in the team project was marked with a red cross and thus inaccessible.
Simply upgrade your Visual Team System 2008 WITH team explorer installed to SP1
Simply upgrade your Visual Team System 2008 WITH team explorer installed to SP1
Saturday, October 04, 2008
Microsoft Project Server 2007
I finished installing microsoft Project Server 2007. I came across 2 issues.
The first one was the 2 Services (Microsoft Office Project Eventing Service and the Queue service) not starting this happens when the machine is not connected to the internet and tries to get some certificates from:
http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
When you try to start them manually you get "Service did not respond in a timely fashion" and in the Eventlog you have: "Unexpected exception occured".
This can be solved by using this woirkaround:
"
Manually add the CRLs from the above Urls to the server manually (assumes
you've downloaded them locally first):
certutil -addstore CA CodeSignPCA.crl
certutil -addstore CA CodeSignPCA2.crl
Resolution Workaround (don't try this unless you've exhausted everything
else):
We haven't tried this yet, but it is our hunch that if you cannot allow the
server access to the internet that it may be possible to fool .Net into using
locally hosted .crl files. This could only work if the restrictions that
prevent the service account and server reaching the internet still permit a
loop-back request to itself (calling web pages from the local server).
The way to do this is to add this to your HOSTS file on the servers:
127.0.0.1 crl.microsoft.com
"
or make sure you are connected to the internet for the easy solution :p
the other one was that jobs got stuck in the queue in "Waiting to be processed status". This I solved by running the service under the same credentials as the SSPService account.
that all for now folks :)
The first one was the 2 Services (Microsoft Office Project Eventing Service and the Queue service) not starting this happens when the machine is not connected to the internet and tries to get some certificates from:
http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl
http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl
When you try to start them manually you get "Service did not respond in a timely fashion" and in the Eventlog you have: "Unexpected exception occured".
This can be solved by using this woirkaround:
"
Manually add the CRLs from the above Urls to the server manually (assumes
you've downloaded them locally first):
certutil -addstore CA CodeSignPCA.crl
certutil -addstore CA CodeSignPCA2.crl
Resolution Workaround (don't try this unless you've exhausted everything
else):
We haven't tried this yet, but it is our hunch that if you cannot allow the
server access to the internet that it may be possible to fool .Net into using
locally hosted .crl files. This could only work if the restrictions that
prevent the service account and server reaching the internet still permit a
loop-back request to itself (calling web pages from the local server).
The way to do this is to add this to your HOSTS file on the servers:
127.0.0.1 crl.microsoft.com
"
or make sure you are connected to the internet for the easy solution :p
the other one was that jobs got stuck in the queue in "Waiting to be processed status". This I solved by running the service under the same credentials as the SSPService account.
that all for now folks :)
Subscribe to:
Posts (Atom)