Use the following
SELECT Doc.value('data((/OrganisationAccountOpeningForm/KYCCustomer/EntryDate)[1])','datetime')
or syntactically
SELECT <XML Column Name>.value('data((/<XPATH>)[<1-based index into possible values returned>])','<Format to convert the XML value into>')
See also http://msdn.microsoft.com/en-us/library/ms345117(SQL.90).aspx
Make since that the "show original tagged notes as dimmed" option is set. This then lets you start a new summary page each day that brings forwards any incomplete items.
· Log on to Server as local admin account e.g. User,
o Run Visual Studio remote debugger remotely (Deployed to Dev workstation as part of Visual Studio install, can be installed on server).
o Transport qualifier will be shown in first line as <User>@<Server>
o Add Developer to Permissions in remote debugger. (Menu item)
o Optionally - Use IISApp.vbs to determine which process ID is hosting your website
· On Developer Machine
o Add new local User (with same password as Server) to your local machine as an Administrator
o Allow cross user debugging
§ Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Machine Debug Manager]
"AllowLaunchAsOtherUser"=dword:00000001
o Open VS
o Open Debug->Attach to Processes (Ctrl-Alt-P)
o In the transport Qualifier change from your local machine to the value shown on remote machine as <User>@<Server>
o Click Refresh
o Jump down to w3wp.exe, select the correct process ID
Something I really whould have known. How much time have I spent loading all processes in remote debugger and detaching one by one because they have the wrong dlls loaded.
No more. Just run
iisapp.vbs
to get
C:\Documents and Settings\me\Desktop>iisapp.vbs
W3WP.exe PID: 7812 AppPoolId: DefaultAppPool
W3WP.exe PID: 6516 AppPoolId: security
W3WP.exe PID: 7848 AppPoolId: Cosmos
W3WP.exe PID: 10120 AppPoolId: Employer.VersionService
W3WP.exe PID: 9700 AppPoolId: DefaultASP
W3WP.exe PID: 6288 AppPoolId: IssueManager
W3WP.exe PID: 6348 AppPoolId: Employer.Expenses
W3WP.exe PID: 9876 AppPoolId: Employer.Invoices
W3WP.exe PID: 7932 AppPoolId: Employer.Portal
W3WP.exe PID: 8648 AppPoolId: IMv1
I've just seen some of the worst code of my life... fortunately it was from an AutoGenerated application. Lets start with this pValue = Utility.GetParam("issue_id");Response_issue_id.Value = pValue;
if(Session["UserID"]!=null)
pValue = Session["UserID"].ToString();
else
pValue="";Response_user_id.Value = pValue;
pValue = Utility.GetParam("assigned_to");
Notice that after the else, you will see that there are two statements on one line. Due to the fact that there is no bracket, the 2nd statement will also be executed when the condition was met as well.
After that we see loads of
pValue = Utility.GetParam("assigned_to");
try
{
Response_assigned_to.SelectedIndex=Response_assigned_to.Items
.IndexOf(Response_assigned_to.Items.FindByValue(pValue));
}
catch{}
pValue = Utility.GetParam("priority_id");
try
{
Response_priority_id.SelectedIndex=Response_priority_id.Items
.IndexOf(Response_priority_id.Items.FindByValue(pValue));
}
catch{}
Where this pattern is repeated for about a dozen fields. Don't run this code with "Break when an exception is thrown" switched on.
However my personal favourite is
Decimal.Parse(CCUtility.GetFormattedNumeric(mydec,CCUtility.defaultReturnedNumeric.BlankString ));
The point here is that CCUtility.GetFormattedNumeric attempts to parse a string into a numeric (again with a try catch around a Decimal.Parse) and then returns ToString("0.#####"). If the string isn't a number then it returns the 2nd argument, which is CCUtility.defaultReturnedNumeric.BlankString but of course that fails the Decimal.Parse. Shame they didn't use the alternative value CCUtility.defaultReturnedNumeric.Zero and saved two exceptions being thrown.
Its always amazing how different places handle events outside of the norm. Take today's heavy snow for example. I am sitting on a train travelling over 100 miles through white countryside, leaving huge swirls of displaced snow, and we are on time. As the train tilt's I can see the rails on the line next to me and the snow is occasionally covering them, but normally its only half way up, and we plough on, flat out. I'm heading to a city that isn't even running busses or tubes. I'm going to have to walk the last mile or two to get to the office. The funny thing is as we come in through Wembley is that I see less snow than I scrapped off my car this morning. On the other hand I've just seen an accident out the window. A silver Vectra crashed into the back of a green Micra just by the Ace Cafe. Of course this is no worse than Lichfield where I was nearly hit by a red Micra as it locked up and slid out of a side-road. I just watched them hit the kerb and spin into my lane while I "overtook" into the empty oncoming traffic lane. When it snows, forget the brake pedal, it just gets you into trouble. Train announcement, looks like we'll be just a few minutes late this morning. Now that's one thing I won't moan about.
Martin Fowler recently published CheaperTalentHypothesis on the cheaper cost of more expensive programmers. I apologise for hacking this down Naturally better programmers cost more, either as full-time hires or in contracting. But the interesting question is, despite this, are more expensive programmers actually cheaper?.... .....If you can find a factor-2 talented programmer for less than twice of the salary of an average programmer - then that programmer ends up being cheaper. To state this more generally: If the cost premium for a more productive developer is less than the higher productivity of that developer, then it's cheaper to hire the more expensive developer. ..... There are some notable consequences to the the cheaper talent hypothesis. Most notably is one that it actually follows a positive scaling effect - the bigger the team the bigger the benefits of cheaper talent. Let's assume...a team of ten talented developers ... twice as productive as the average ... assume that a rival team of average programmers would be a team of twenty. ... Software development depends very much on communication between team members. .... As a result productivity scales ... I'm inclined to guess at [productivity] being closer to the square root. If we use my evidence-free guess as the basis then to get double the productivity we need to quadruple the team size. So our average talent team needs to have forty people to match our ten talented people - at which point it costs twice as much. Another factor that plays a role here is time-to-market. ... discount the previous paragraphs, and assume the talented team is only twice as productive as the average team. ... ... the talented team wins again. They'll complete the project in half of the time of the average team, .... What Martin hasn't covered here is the further scaling caused by offshoring. My experiences have led me to believe that there is a further productivity scaling to be gained by the trust that is implicit between the onshore and offshore components. I have been running an offshore team over the last 15 months, I have had one or two onshore contacts and 4-7 offshore team members.. At the beginning the period I was production support focused and just let them get on with it. They were inefficient. I started with a very close coupling, work was handed out piecemeal and thoroughly scrutinised on return, feedback was often pedantic with references to coding standards not being followed. However after 6 months, management allowed me to focus on Dev full time. Initially key pieces of work including prototyping were kept onshore. Overtime, Trust developed. Now whole swathes of development have been handed over from start to finish. In addition code review quality is well up, and so they now are performed at random only. Now we come to the bit that caught my eye. Agile development further accelerates this effect. A talented team has a faster cycle time than an average team. This allows the full team to explore options faster: building, evaluating, optimizing. This accelerates producing better software, thus generating higher value. This compounds the time-to-market effect. (And it's natural to assume that a talented team is more likely to produce better software in any case.) This correlates with my findings on offshoring. With a team in a single time zone, the feedback cycle is much shorter. In the early days I was working from 7am till midnight trying to "extend the timezones" and get better overlap with the team members. Now I just hand over a full piece and since I trust them to come up with good solutions I can let them worry about the details in their own timezone. Faster cycle time leads to a better external product, but perhaps the greatest contribution a talented team can make is to produce software with greater internal quality. It strikes to me that the productivity difference between a talented programmer and an average programmer is probably less than the productivity difference between a good code-base and an average code-base. Since talented programmer tend to produce good code-bases, this implies that the productivity advantages compound over time due to internal quality too. Martin's final thoughts are on measurement, which I think is a thoroughly good idea ...At ThoughtWorks we rely on peer assessment - developers abilities are assessed by fellow team members. The result is hardly pinpoint precision, but it's the best anyone can do. ... ... I believe that if the software industry is to fulfil its potential it needs to recognize the cheaper talent hypothesis and close the gap between high productivity and higher compensation. Oh if only :-) Sorry I was assuming I am productive there for a moment. Technorati Tags: Offshore, Work, Productivity, Peer Assesment, Compensation
This gem is in the comments, 2nd one down. Lesson learned: even Einsteins become Morts when faced with a deadline. From The Greatest Compliment A Developer Can Receive See also http://www.nikhilk.net/Personas.aspx It got me thinking about my current employment. We have the right ingredients for perfect code, but somehow nobody seems happy with the end result. Don't get me wrong, we deliver on time every time, and with the features we agreed to, but too many of us feel we could produce better code behind the scenes. Maybe it's the deadlines
Strange as it seems but “Server encountered an internal error. For more information, turn on customErrors in the server’s .config file.” is actually begging for you to add,
<system.runtime.remoting>
<customErrors mode="off"/>
</system.runtime.remoting>
Thanks go to Chris Taylor for pointing this out. I didn't think it ever seemed to work properly before!
http://dotnetjunkies.com/WebLog/chris.taylor/articles/5566.aspx