Running through the universe, 42 steps at a time

Op stap naar de Acerta Ekiden

noreply@blogger.com (Sam) — Tue, 03 Nov 2015 12:01:00 +0000

In de categorie "doe eens iets met je werk" zijn we niet zo lang geleden met 12 man van Infohos Services naar Brussel getrokken om mee te doen met de Acerta Ekiden!

De Ekiden, een aflossingsmarathon, is een traditie die overgewaaid is uit Japan, en die nu meer en meer wordt georganiseerd in onze contreien. Brussel is hier wel de grootste van en ook deze keer deden niet minder dan 1650 teams (van 6 personen elk) hier aan mee.

Aangezien de loopkriebel blijkbaar ons bedrijf geïnfecteerd heeft (cfr eerdere deelname aan de 'Wings for Life' in Ieper), werd er beslist om ook hier aan mee te doen, en we slaagden erin om twee teams samen te stellen (wat zeker niet slecht is, 12 man op een bedrijf van 90).

Zoals altijd vereist in Brussel geraken een beetje organisatie, maar gelukkig was het op een zaterdag waardoor de E40 niet zo erg is als gebruikelijk.
Als eerste stap Cyriel naar zijn peter gebracht voor een korte babysit, tot Nele klaar was met werken (merci Bert&Lot).
Daarna een tussenstap in Heule om Jesper, collega #1, op te pikken.
Daarna een tussenstap in Deinze om zelf van auto te wijzigen en met Wim, collega #2, en zijn vrouw mee te rijden naar de Heyzel.
Eenmaal geparkeerd, was het nog een wandeling van 10 minuten van parking C naar het stadion, maar dan waren we er eindelijk.

First things first, iedereen kostuum aantrekken en de obligate groepsfoto!

Daarna was het tijd om het stadion te bekijken, voor mensen die dit nog nooit gezien hebben was dit best indrukwekkend, al waren er toch ook mensen die het groter verwacht hadden.

Daarna was het tijd voor de serieuze zaken! Onze eerste lopers van elk team vertrokken buiten het stadion, en de rest van onze teams posteerden zich in de tribunes dicht bij onze wisselzone. Dit ging niet zo eenvoudig, aangezien zowat iedereen blijkbaar dit idee had en de doorgang van tribune naar tribune niet echt ... optimaal is in het Heyzel stadion. Laat ons zeggen dat ik een nieuw begrip heb opgedaan van hoe het Heyzel drama in de tijd is kunnen ontstaan... Maar uiteindelijk stonden we toch klaar.

De eerste lopers kwamen al puffend terug; blijkbaar is Brussel nogal aan de heuvelachtige kant. Iedereen die al de 20km van Brussel heeft gelopen kan dit beamen.

In het begin ging het vrij op en neer tussen onze twee teams (een beetje interne concurrentie is altijd leuk), in zoverre zelfs dat onze 4de lopers quasi gelijktijdig uit de wisselzone vertrokken! Spannend, maar daarna was het een beetje naar de knoppen gezien de loper van het 'andere' team vlotjes 40 minuten liep op de 10km en onze loper 'slechts' 51 minuten kon halen. Dus de kloof was geslagen, en werd nog een 6-tal minuten uitgediept door de volgende loper.

Daarna was het eindelijk aan mezelf; dus op naar de wisselzone, samen met Jesper die laatste loper was voor het andere team.

Er zijn duidelijk voor-en nadelen om als laatste loper te starten. Voordeel is dat je de rest van je team goed kan aanmoedigen, en voldoende tijd hebt om je klaar te maken. Nadeel is dat je daar wel een paar uur staat te draaien, en dreigt een beetje te verkleumen.

Het eigenlijke lopen ging vrij goed, rekening houdende met het inderdaad extreem heuvelachtige terrein. Hoogtepunt was toen ik Tia Hellebaut kon inhalen! Toegegeven, ze is ook al even gestopt met topsport, en dat ging waarschijnlijk niet gelukt zijn in haar hoogdagen. Maar toch, ingehaald is ingehaald. Sympathieke madam overigens, Tia, die me spontaan aansprak wanneer ik haar inhaalde om te weten hoe ver we al gelopen hadden (en nogal teleurgesteld was dat het 'nog maar 3 km was :D).

Uiteindelijk afgeklokt op een respectabele 34.45, en aangezien ik verre van een heuvelloper ben, was ik daar best tevreden van.

Daarna nog wat post-run schmoozen met de collega's, in de file staan aan parking C en uiteindelijk toch thuisgeraakt. Een lange, maar leuke dag!

Preparing for the half marathon

noreply@blogger.com (Sam) — Sun, 25 Sep 2011 22:16:00 +0000

Because life is about trying new things, I've undertaken the task of running not one but two half marathons in 2 consecutive weeks, one in Kuurne and one in Oostende.

Now, the 'serious' runner is going to scoff at this and boast that he or she once ran 4 marathons in 4 days or similar. Fair enough, but keep in mind that running is but one aspect of my life. Between a fulltime job, a girlfriend, a busy social life, other sports and the horrid Belgian weather, I count myself lucky to get 2-3 solid running sessions in one week (and that's counting weekends!). So maybe 2 1/2 marathons are not that trivial after all.

Having said that, I'm fairly sure I can do it, I've been training quite dilligently (for my doing anyway ;) and have succeeded in varying my training load as well, alternating long distance runs (10k, 15k) with interval runs (speed work). I'm hoping the combination of the two will give me good endurance and some decent speed as well. Because, since we're a bit ambitious as well, just finishing them is not enough, secretly I'd like to come in under 2 hours as well. A feat which is not impossible, but will require a good deal of concentration and (especially) enough discipline not to go running off like a madman from the start, and paying the price later.

We'll see in the next two weeks.

(Also if I don't update in the next 3 weeks, call an ambulance pls :).

Run Run!

noreply@blogger.com (Sam) — Thu, 15 Sep 2011 17:15:00 +0000

Finally managed to get myself running again tonight.

http://runkeeper.com/user/polkadragon/activity/52339199

Slow eh? Now keep in mind, it was an interval training. Which means you run for a certain period at maximum capacity, and then follow that up with a slow period to recover. Then fast again, then slow again. Rince, repeat.

In my case it was:
5 minute warmup slow-ish
1 minute fast
1 minute slow
(repeat 10x)
5 minute cooldown slow-ish

I can assure you that by the third fast bout, you feel like dying, that one fast minute feels like half an hour and that slow minute whizzes by!
The general idea is that interval training improves your aerobic capacity (increasing your speed), the high intensity intervals are supposed to boost your metabolism.

For sure, my metabolism is telling me something now. Although it might be "call the hospital", not entirely sure.

Reading data from a closed Stream

noreply@blogger.com (Sam) — Thu, 15 Oct 2009 12:48:00 +0000

Problem:
Sometimes you need to read data from a Stream, either to save it or to process it in other layers, but you really don't want to open or pass along the Stream for too long.

Solution:
At first glance, the GetBuffer() method of the Stream object would seem ideal, since it copies the text to a byte array, allowing you to close the underlying stream without any issues.

However, GetBuffer has some definite issues, the biggest one being that he will pad the resulting byte array with "\0" (nulls), depending on how big the data in your stream is. Which can lead to all kinds of nasty side-effects (in particular when working with XML data).

Never fear, in comes the rescuer, in this case the ToArray() method of the Stream object. This basically does everything GetBuffer does, minus the padding. And likewise, you can simply dispose of the Stream and do whatever you need to do with the data.

How to retrieve an old version of your project in Sourcesafe

noreply@blogger.com (Sam) — Thu, 15 Oct 2009 09:50:00 +0000

• Open Command Prompt

• Set Sourcesafe Directory

C:\Program Files\Microsoft Visual Studio\VSS\win32>set SSDIR=<unc path to your sourcesafe root>

• Execute GET command

ss get $/ -R -Vd5/6/2009;5:16a -I-N -W -GLD:\temp\<your project name>-GTM –GWR

- Project: $/Projects/<your project>: naam van het project die je wilt hebben
- -Vd5/6/2009;5:16a: tijdstip van de bestanden die je wilt terugkrijgen (DD/MM/YYYY formaat, dus 5 juni in dit geval)
- -GLD:\temp\<your project>: lokale folder waar de files in moeten terechtkomen

Quick Linq tip

noreply@blogger.com (Sam) — Fri, 09 Oct 2009 08:26:00 +0000

When you crete a construction such as

if (list.Count > 0)
{
// do stuff
}

its actually much more efficient to use LINQ as such:

if (list.Any())
{
// do stuff
}

Advantage: ANY will stop after the first hit, while COUNT will traverse the entire enumerator. This can be significant for larger lists.

Validation for ComponentArt datepicker

noreply@blogger.com (Sam) — Fri, 09 Oct 2009 08:18:00 +0000

External DatePicker Controls can be useful, and the ComponentArt sure is, except for the annoying lack of client-side validation. Nevertheless, its not too hard to integrate your own javascript and validate your date entries.

This sample uses Prototype, but you can simply replace the '$' by 'document.getElementById' and you should be okay.

(This also assumes you have encapsulated your date picker in a user control)

1.Add a (hidden) div element to your user control

<div style="display:none" id="validationdiv<%=ClientID%>">
<asp:TextBox ID="ValidationTextBox" runat="server" EnableViewState="false"></asp:TextBox>
</div>

2. Add a RequiredFieldValidator, pointing to our hidden TextBox

<asp:RequiredFieldValidator Enabled="false" ID="dateValidator" ControlToValidate="ValidationTextBox" runat="server" ErrorMessage="***" Display="None"></asp:RequiredFieldValidator>

3.Expand your javascript handlers, to change your textbox values when the Calendar/Picker values change.

function MarkAsValidationOk<%=ClientID%>()
{
$('<%=ValidationTextBox.ClientID%>').value = true;
}

function MarkAsValidationNOk<%=ClientID%>()
{
$('<%=ValidationTextBox.ClientID%>').value = “”;
}

function Picker1_onSelectionChanged(sender, eventArgs)
{
sender.AssociatedCalendar.setSelectedDate(sender.getSelectedDate());
MarkAsValidationOk<%=ClientID%>()}

function Calendar_OnSelectionChanged(calendar)
{
calendar.AssociatedPicker.SetSelectedDate(calendar.GetSelectedDate());
MarkAsValidationOk<%=ClientID%>()}

function ClearCalendar<%= Calendar1.ClientObjectId %>()
{
<%= Calendar1.ClientObjectId %>.ClearSelectedDate();
<%= Picker1.ClientObjectId %>.ClearSelectedDate();
MarkAsValidationNOk<%=ClientID%>()
}

4. Add some configuration settings to your user control Codebehind.

public bool EnableValidation { set { dateValidator.Enabled = value; } }
public string ValidationErrorMessage { set { dateValidator.ErrorMessage = value; } }
public string ValidationGroup { set { dateValidator.ValidationGroup = value; } }

5. Expand your 'setdate' server-side functionality to flag validation as ok.

public void SetDate(DateTime date)
{
Calendar1.SelectedDate = date;
Picker1.SelectedDate = date;
timeSelectorControl.DefaultHour = date.Hour;
timeSelectorControl.DefaultMinute = date.Minute;

Page.ClientScript.RegisterStartupScript(GetType(), "datejs" + ClientID, "MarkAsValidationOk" + ClientID + "();", true);
}

6. All done, now you can simply enable validation by setting some properties in the page that uses your control:

<uc1:CalendarPicker ID="birthdayPicker" EnableValidation="true" ValidationGroup="EmployeeValidationGroup" ValidationErrorMessage="BirthDate_Required" runat="server" ShowTimePart="false" />

Selecting all checkboxes with Prootype

noreply@blogger.com (Sam) — Fri, 09 Oct 2009 08:07:00 +0000

For creating a "Select All Checkboxes" link in javascript:

function CheckAll()
{
var allCheckboxes = $$('input[type=checkbox]');
allCheckboxes.each(function(e) { e.click(); });
}

Don't use e.checked = true, because it doesn't trigger the Grid_Item_CheckChanged events of the ComponentArt grid.

Mind your callbacks

noreply@blogger.com (Sam) — Wed, 30 Jan 2008 11:11:00 +0000

These days I'm using quite a lot of Callbacks, that is requests to the server that don't refresh the entire page, but only a specific section, creating the illusion of a snappier user interface. As such, they are becoming a necessity in these days of Users 2.0 (ie users who have gotten used to Web 2.0 functionalities, much as I loathe the term).

Google were one of the main early adopters of callbacks, but now everyone is doing it, and so are the main out-of-the-box software vendors such as Telerik or ComponentArt. These days the challenge would be to find a grid that does not implement the latest AJAX-style gadgets.

Our 3rd party vendor of choice is currently ComponentArt, and I've been using their Callback mechanisms quite extensively lately. They're quite good, although sometimes its still necessary to go down to the nitty-gritty of client-side scripting, which is not for the faint of hearted.

Of course, while callbacks are great, they tend to have a big impact on they way your applications are constructed, amongst others interfering with what we consider "best practices", such as:

* Strong Typing (hello Mr JavaScript)
* Error Handling (an alert window does not make an error handler)
* Intellisense (maybe not a best practice, but damn handy to have anyway)

Anyway, in the end its just (yet) another technology paradigma shift and most of those "best practice" challenges can be solved decently enough, given a little time and effort. Lets take error handling as an example:

Problem: When an error occurs during a Callback, the typical error message is "Data cannot be loaded", delivered in the form of a javascript alert. Not too useful, not to mention the fact that your page is potentially left in a compromised state.

Solution: In the end, the Callback method is just another server-side method, so encapsulate it in an try/catch block and provide adequate error handling. After that, generate some client-side script to redirect the user away from the page to some nice error page.

protected void MyCallBack(object sender, CallBackEventArgs e)
{
try
{
BindGrid();
panel.RenderControl(e.Output);
}
catch(Exception ex)
{

new ErrorReporter().HandleError(Request, ex);
CallBackErrorHandler.RedirectToErrorPage("Error.aspx", panel, e.Output);
}
}

and then in our CallBackErrorHandler class:

public static class CallBackErrorHandler
{
public static void RedirectToErrorPage(string redirectUrl, Control container, HtmlTextWriter output)
{
string str = "<script type='text/javascript'>";
str += "window.location = '" + redirectUrl + "'</script>";
Literal lit = new Literal();
lit.Text = str;
container.Controls.Add(lit);
container.RenderControl(output);
}
}

Old tricks, new techology :)

Dynamic Services

noreply@blogger.com (Sam) — Mon, 21 Jan 2008 12:24:00 +0000

Something useful I recently learned:

While you can without any problem attach parameters to a .NET Windows Service (by means of a configuration file), how the heck am I supposed to enter parameters into the INSTALL program itself (such as, the service name...).

The answer was simple: InstallUtil.exe (the installer program) can actually be called with command-line parameters appended to it. These can then easily be processed in the installer class itself.

installutil /DisplayName=Sam " WindowsService1.exe"

And then in your installer.cs file:

protected override void OnBeforeInstall(IDictionary savedState)
{
base.OnBeforeInstall(savedState);
string name = Context.Parameters["DisplayName"];
if (name != null)
serviceInstaller1.ServiceName = name;
}

Take care: this needs to happen in your OnBeforeInstall handler, after that your Context will be NULL!

WebExceptions and you

noreply@blogger.com (Sam) — Thu, 17 Jan 2008 15:06:00 +0000

Every now and then, one of my applications was throwing up an error of type 'System.Net.WebException: The request was aborted: The request was canceled'.

This happened during execution of a SOAP webservice call towards a backend system. Problem was, it was almost impossible to reproduce, happening as it did on irregular, non-deterministic moments. I only noticed it because of an automatic error reporter, which automatically mails any exceptions to a public Outlook folder.

After finding some time to investigate the issue, I found that it was apparently a known issue, related to the Keep-Alive property of the HTTP Request itself. Apparently, every now and then, IIS ate the webservice request, when Keep-Alive was true.

One possible solution was of course to disable Keep-Alive on the IIS level. While this would no doubt solve the problem, it is kinda overkill and can have negative implications on the performance of the application as a whole (Keep-Alive is there for a reason, you know).

A better solution is to disable Keep-Alive for the SOAP request only, and leave it on for the other requests. This was slightly complicated by the fact that - like most .NET users - we don't actually code our webservice consumption classes ourself, but use generated Proxy classes, obtained by either wsdl.exe or by adding a Web Reference in VS.NET. Luckily, by means of a simple subclass, we could dance around this problem and keep our code generation intact.

public class MyCustomService : MyGeneratedService
{
protected override WebRequest GetWebRequest(Uri uri)
{
HttpWebRequest request = (HttpWebRequest)base.GetWebRequest(uri);
request.KeepAlive = false;

return request;
}
}

After introducing these changes for each SOAP request, the intermittent WebException has dissapeared. Life is good.

Making perfect software in a non-perfect world

noreply@blogger.com (Sam) — Wed, 12 Sep 2007 20:20:00 +0000

Ideally, every software project would be lavishly described and work in his own little world, having a dedicated database and no dependencies that slow you down. In such conditions, you can just sit yourself down, and work uninterrupted, quickly reaching Programming Nirvana.

Of course, no real project is ever like that, so the trick then becomes how do we work in an environment where your data is spread out over several applications, and these applications each have their own timetable and their own priorities. One of the possible techniques is called Stubbing.

Stubbing or Mocking is a technique that is much better described by the likes of Martin Fowler, and other high-profile architects but in short, its a way of first hiding away the implementation of a complex subsystem by only exposing the interface to those applications that will be using it and then code against a simplified (or dummy) implementation of that interface, while the 'real' application is being made.
This allows you to continue with the rest of your app, and come back to the subsystem
when you have successfully driven your users into a corner and forced them to do their work.

The concept of Stubbing seems to scare a lot of developers, because on the surface it seems to be something for huge projects and - lets face it - is often explained in needlessly complex terms. This is unfortunate because even in smaller projects, stubbing can be a very useful technique and doesn't have to be extremely complicated.

An example to illustrate.

You're tasked to implement a medium-sized SOA project, but you need to get some data from your local AS400 system. Unfortunately, the AS400 guy has just fallen off his roof and will be out for the next two weeks. So instead of twiddling your thumbs for two weeks, Stubbing will allow you to implement the other tasks at least and leave the implementation of the AS400 subsystem for later.

So what we need is essentially a system that is going to pretend to be an As400 and that allows us to "plug" this in dynamically (meaning, when the actual AS400 application becomes available, we don't have to change much code - preferably none!).

To implement this, we'll start by creating an Interface. Learn to love those, they are your best friend.

public interface IAs400Connector
{
PORT GetLines(string user, string from, string to);
}

Next step, create our 'stub' class and implement this interface.

public class StubAs400Connector : IAs400Connector
{
public PORT GetLines(string user, string from, string to)
{
string fileName = "Sample.xml";
string xml;
using (StreamReader streamReader = new StreamReader(fileName))
{
xml = streamReader.ReadToEnd();
}

return XmlPortSerializer.DeSerialize(xml);
}
}

When creating a stub class, its always a good idea to structure your stub data as close as you can to the original data. That way, you'll limit the work you have to do when you plug in the real class later on. In this particular instance, we assume that the AS400 developers can give us a DTD or a Schema beforehand, so we can easily generate some sample data which should be very similar to the real thing (in theory). Implementation then simply consists of reading the XML sample file, and deserializing it into a custom object (which has been previously generated by a tool such as XSD.exe).

The hard? part is mostly done now, all that remains is to implement a little Factory, so that the calling application doesn't have to worry about instantiating the right Connector. In fact, we'll go one step further and push that decision right to the configuration file.

public static class As400ConnectorFactory
{
private static IAs400Connector connector;

public static IAs400Connector GetAs400Connector()
{
if (connector == null)
connector = (IAs400Connector)Activator.CreateInstance(Type.GetType(Settings.Default.As400Connector));

return connector;
}
}

There's a few things going on here. First of all, we make use of the Properties feature of .NET 2.0, in which you can include dynamic,
strongly-typed properties in your project and have those populated by the calling application through means of a configuration file, as seen below. These settings can then be called in your application, through an (autogenerated) strongly-typed Settings class.

<configsections>
<sectiongroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="Project.As400Connector.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirepermission="false">
</section>
</sectiongroup>

<applicationsettings>
<project.as400connector.properties.settings>
<setting name="As400Connector" serializeas="String">
<value>Project.As400Connector.StubAs400Connector, Project.As400Connector
</setting>
</project.as400connector.properties.settings>
</applicationsettings></configsections>

Second, we then use Reflection to instantiate the Connector specified in the configuration file.

connector = (IAs400Connector)Activator.CreateInstance(Type.GetType(Settings.Default.As400Connector));

If you're worried about using Reflection to create your class on every request, just make the connector static like I did, that way it'll get cached. Keep in mind that you'll need to reset the application then, if you want to force a change in connector. Of course, if you use this in a web context, changing the Web.Config will automatically reset your application anyway, so its a moot point :)

Now, you can merrily start designing your screens and grids and lists and whatnots, without stressing about the lack of data. Once your AS400 boys then finish their work, you code the 'real' Connector class, switch to it in your configuration file and test with the real data. If everyone has done their homework, the work left should then be minimal (mostly validating the length of the real data and taking out some inevitable quirks).

While this is obviously a very simple example, in larger projects nothing is stopping you from implementing a much more complex stubbing system, if needed.

Not for publication

noreply@blogger.com (Sam) — Thu, 11 Jan 2007 15:11:00 +0000

After performing a "Publish website" operation on my ASP.NET 2.0 web project, I got the following error upon browsing to the newly-deployed site:

CS0433: The type 'ProfileCommon' exists in both
'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
Files\root\dc8cbf9e\f05d928b\assembly\dl3\2f0caf74\881e5468_eec7c601\App_Code.DLL'
and 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET
Files\root\dc8cbf9e\f05d928b\App_Code.r_z1bmqm.dll '

which is of course quite nonsensical as the two directories listed above are in fact the same.

After some investigation, I found that the root of the problem was that I had marked the website as "Precompiled" during the publish operation AND I had subsequently deleted the "PrecompiledApp.config" file upon completion...

Apparently, that little config file tells the Dotnet runtime that the file is already compiled, and as such shouldn't be compiled (again). Without that file, all kinds of conflicts arise between the precompiled files and the newly-compiled file.

So, in summary.

Publishing websites precompiled GOOD ^-^
Deleting PrecompiledApp.config afterwards BAD >.<

The Case of the Overzealous Profile

noreply@blogger.com (Sam) — Tue, 28 Nov 2006 12:14:00 +0000

Asp.NET 2.0 ships with a wonderful feature called "Profile", which is essentially a server-side replacement for cookies, most commonly used for persisting user settings. The advantage of the server-side solution being of course that you're not dependant anymore on users actually supporting cookies and/or deciding to delete them in a sudden fit of paranoia. ***

Another nice thing about the Profile is that it follows the Provider model and ships with a pre-working SQL Server implementation.

In a recent ASP.NET application, we made some extensive use of the Profile in our searchscreens, however since we were working on an Oracle database, we had to create our own custom Provider. This is however absolutely no problem since DotNet makes it really easy to do so, and to plug your resulting custom provider into your application without any hassle.

However, we did notice a performance degradation upon use of the Profile, and we occasionally even got Oracle errors, when the application received a lot of strain. When we finally found some time to investigate the issue, we discovered that the SetPropertyValue method of the Provider was being called on each and every visit to the page and this for every available property in our Profile, resulting in at least 15-20 extra database calls per page access. Needless to say, this did not help performance one bit.

After digging around some more, it turned out that the Profile mechanism has in fact an auto-load and auto-save mechanism built-in. In other words:

at the start of the page cycle, all properties get read from the data store
at the end of the page cycle, all properties get persisted to the data store

Fortunately, there was also an option to turn this automatic save off, this by a simple modification of the web.config.

< profile automaticSaveEnabled="false">

Not quite as well-documented as I'd hoped though...

*** Note that the Profile can however be enabled for anonymous usage, in this case you will need cookies again for this to work. :)

How to take Control... of your controls

noreply@blogger.com (Sam) — Mon, 27 Nov 2006 12:30:00 +0000

When creating custom ASP.NET controls, there's the question of which baseclass to use for your control.
Generally speaking, you have three big categories:

Rendered Controls
Container Controls
Inherited Controls

Of those choices, inherited controls are the simplest, in that they simply inherit from an existing control (custom or otherwise). An example would be inheriting from a DropDownList and adding some custom code to pre-populate it. Or a ConfirmButton control, which inherits from Button, and automatically renders a "are you sure?" javascript alert when you click it. Inherited Controls are to be used when you want all the functionality of a certain control, and then just "something" extra.

Rendered Controls are created by inheriting from the WebControl class. They operate by directly injecting HTML into the output stream. As such they bypass the normal event lifecycle for any of its containing subcontrols. The result is that a Rendered Control will render much faster than a Container Control, but does not support event postbacks 'out-of-the-box'. While it is possible to provide these events, by means of implementing IPostBackEventHandler and IPostBackDataHandler, and then providing custom code to handle these events, this does raise complexity a bit and tends to create quite cluttered code. It is advisable then, to only use Rendered Controls, for simple, mostly static controls.

Container Controls, as their name implies, function as containers or collections for other controls. They are implemented by inheriting from CompositeControl. Your subcontrols are dynamically added to the Control collection of your CompositeControl, and they will then go through their normal event lifecycle, allowing you to customise them as needed. While this functionality comes at a price (somewhat worse performance compared to Rendered Controls), it allows you to build your webcontrols in a true object-oriented fashion, and apply all your usual Design Patterns to them. It also makes it much easier to inherit from your own controls, and in doing so, create an reusable and extensible library of server controls.

The choice between those three types of controls is - as is usually the case - dependant on the requirements of your project, but generally speaking, Composite Controls will be your best friend the moment your controls become a bit more complex and require event interaction.

Sometimes it really is _that_ easy

noreply@blogger.com (Sam) — Tue, 14 Feb 2006 20:55:00 +0000

Sharepoint has a Page Viewer webpart, allowing you to integrate external applications into your Portal. Very useful, but sometimes this presents problems of its own.

Case in point, one of our clients used this webpart to integrate his .NET web application in a WSS site, and had some trouble with his Session variables not showing up, when viewed through the webpart. Logical, if you think about it, because the site is being referenced through an Iframe of another site, so your cookies are not going to be accessible. Its not a bug, its a feature! In this case, a security feature, because how would you like it if any external site could just frame you (pun intended) and nose around in your cookies?

Faced with the prospect of having to rewrite his entire application without Session variables, the client's developer started considering jumping off the nearest bridge. That is, until I pointed out to him that he could simply switch the session state handling in his .NET application by modifying the web.config.

< sessionState mode="InProc" stateConnectionString="tcpip=127.0.0.1:42424"
sqlConnectionString="data source=127.0.0.1;user id=sa;password="
cookieless="true"
timeout="20"
/>

By setting the "cookieless" attribute to true, ASP.NET will automatically (and with no impact on the application!), switch from using cookies to track session ids to appending a session identifier to the Url. No fuss, no need to rewrite your application!

Problem solved, client happy. If only everything was so easy.

Alive

noreply@blogger.com (Sam) — Tue, 17 Jan 2006 08:02:00 +0000

Yes, I'm still alive.

I'll post a proper update soon, but in the meantime, this might be a good read.

Tale of conversion from an ASP.NET 1.1 application to 2.0

Old Dog, New Trick

noreply@blogger.com (Sam) — Mon, 14 Nov 2005 13:55:00 +0000

Want to implement "Created By" fields for your custom tables in your SharePoint environment?

Fairly easy to do, once you know how to ;)

The trick is to use a not-so-well-kown SQL Server method called "SYSTEM_USER", this will automatically be filled with the SQL Server authenticated user, whether thats a SQL User or a Windows User.

So, first make a CreatedBy field on your table.
Then create an insert trigger, and use the SYSTEM_USER method to fill the field.

CREATE TRIGGER MyTable_FillCreatedBy
ON dbo.MyTable
FOR INSERT
AS
UPDATE MyTable SET CreatedBy = SYSTEM_USER WHERE ID = (SELECT ID FROM INSERTED)

Then of course, you need to correctly configure your authentication towards your custom database.
In case of SQL Authentication, just set the correct user and config in your application configuration file (such as web.config).
In case of Windows Authentication, its somewhat more complicated.
First, you need to change your connection string to Integrated Windows Authentication.

Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=MyDb;Data Source=127.0.0.1

Make sure the 'Identitity Impersonate' tag is also set to true!

Then you need to add the necessary user accounts as logins to your SQL Server. Its generally speaking a good idea to work with a *group*, give that group access to your database and add all users that need access to your group.

The nice thing is that SYSTEM_USER is still going to fill in the individual logged-in user even though only the group has access to the SQL Server.

One big gotcha with Windows Authentication is that it won't work when your SQL Server is on a different server than your Sharepoint (or more in general, IIS) server, at least not when your network is configured with NT Authentication as opposed to Kerberos. There are a few basic fixes for this:
1) Use SQL Authentication ;)
2) Setup Sharepoint to use Kerberos authentication (not so trivial)
3) Setup a 'trust' relationship between the two servers (fiddly)

Need a plumber?

noreply@blogger.com (Sam) — Fri, 14 Oct 2005 12:25:00 +0000

Sometimes with all the glittering IDE's and the Autocomplete features in our development tools, its easy to forget that those too, are just (or have been) someone else's software project and are as such subject to the same deadlines, feature creeps and illogical decisions that our own projects sometimes experience.

Therefore, no matter how shiny a tool may be, always remember that it may have its own logic and ideosyncracies underneath. Because you don't know (and you probably don't *want* to know) what happened in the development lifecycle. Also, most products are really a hodge-podge of various other technologies, some of which were written by 3rd parties, and I'm sure had questionable documentation ;)

Self-proclaimed software guru Joel Spolsky called it the "Law of Leaky Abstractions" in one of his essays and that a pretty good analogy.

We recently met one of those leaky abstractions, in the follow-up of a BizTalk project in which a client had some encoding troubles consuming a .NET webservice from his PHP webserver. In the course of investigating the problem, we traced it all the way from a File Pickup port through an Orchestration schedule, to the Send Port and finally up to the (generated) webservice itself. Having determined that all of the previous steps didn't help in resolving the problem, we then went about the process to change the encoding in the webservice itself (even though its a less-than-optimal solution, because Biztalk regenerates that webservice when you deploy).

So we edited the Web.Config of the webservice, and changed the following line:
<globalization requestEncoding="utf-8" responseEncoding="utf-8"/>
to
<globalization requestEncoding="utf-16" responseEncoding="utf-16"/>

Save web.config, refresh the webservice client, look at the results.
And absolutely nothing changed...

When even a IISReset didn't help the problem (programmer's superstition...), we did some more research and suddenly found this:
http://weblogs.asp.net/tmarman/archive/2004/02/02/66476.aspx

So change that globalization tag all you want, change the encoding by other means, pin needles in a voodoo doll, its just not going to work, because apparently ASMX's are hardcoded to UTF-8...

Make sure you also read the first comment on this blogentry, as its apparently from some Microsoft employee who was involved in the process. ;)

So remember this when next time you wonder why a piece of software doesn't what you wanted. There's probably a leak somewhere ;)

Design vs Deadline

noreply@blogger.com (Sam) — Fri, 07 Oct 2005 14:39:00 +0000

One of the most controversial topics between programmers is the discussion of "design vs getting things done". It takes place on many different levels, from the low-level data-access strategy (DataSets vs Typed Objects), to the higher-level architectural descisions of reusability, extensibility, etc.

The good thing about Microsoft .NET is (IMO) that for the first time - using Microsoft technologies - you can now sort of combine both. .NET allows you to create fully-fledged object-oriented, event-based, strongly-typed applications, which - from a design point of view - are infinitely much better constructed than most VB6 applications. Make no mistakes though, even in .NET its completely possible to write crappy applications, and unfortunately it gets done a lot.

The situation gets even more complicated when you add a product to the mix, lets take - as an example - SharePoint? ;)Sharepoint allows you to extend its out-of-the-box functionality with Webparts, which are really just a specific kind of Asp.Net user controls. Problem is, Sharepoint has its own logic, which makes a number of 'normal' sound design principles more problematic (client-side validation using Validators being one).

Again though, with a little effort, it is possible to create a well-structured application even in Sharepoint. As an example, in a recent project, we needed to create a webpart, which would, when the user put the page in Design Mode, automatically display a fairly complex user administration part. This admin part would then manipulate those values and have to pesist them as properties in the WebPart.

Now, speaking in design terms, two obvious choices presented itself.

1. Implement the functionality in the WebPart itself, resulting in a flat less-complex structure, but also quite quickly leading to spaghetti code, especially if the desired functionality is moderately complex. Plus, from a design POV, the level of abstraction is practically zero, which will not encourage reuse and/or extensions of the webpart.

2. Create a series of ASP.NET user controls, and use LoadControl on the top-level user control to add him to the control collection of the webpart. Its elegant, its sound design-wise, but it does raise the problem, how do we communicate between the 'layers'. Its the classic circular reference problem, webpart needs to know about user control to create it, and user control needs to know about webpart to give some information back to it. Circular references are solveable usually, but even if it was solved it would still leave you with a user control who somehow knows he'll be included in a webpart, which is again Bad Design.

So whats the solution then? Any experienced control builder in .NET will now be screaming it. *Events* of course. That wonderful mechanism, IMO one of the better features of .NET alltogether, that allows us to decouple layers from one another and create true plug-and-play usercontrols.

So, you set up the following situation:

- Webpart creates UserControl through LoadControl
MyCustomControl myControl = (MyCustomControl) Page.LoadControl("MyCustomControl.ascx");

- Webpart subscribes to the OnDataChanged event from the UserControl
myControl.OnDataChanged += new MyDataEventHandler( myControl_OnDataChanged );

- Webpart adds control to his own control collection
pnl = new Panel();
pnl.Controls.Add(myControl);
Controls.Add(pnl);

- Something happens in the control, and it raises the OnDataChanged event. Thats all the control needs to do, no 'upper references' needed.
private void changeButton_Click(object sender, System.EventArgs e)
{
if ( OnDataChanged != null )
{
OnDataChanged (sender, new MyDataEventArgs(e));
}
}
- The webpart receives notification of the event and does whatever it needs to do with it.
private void myControl_OnDataChanged(object sender, MyDataEventArgs args)
{
// do something useful
}

Thats all there is to it, the beauty of it is that you now have a user control which can be easily re-used in another webpart, or in another usercontrol or even directly in an aspx page.
Of course, there are a few SharePoint gotchas that even good design can't solve, but we'll leave those for another time ;)

To fill the void

noreply@blogger.com (Sam) — Sun, 25 Sep 2005 07:27:00 +0000

Welcome to (yet another) technology blog.

In here, I'll mostly be talking about my (mis) adventures in the land of technologies such as BizTalk, ASP.NET and SharePoint 2003. If the mood strikes me, I might even get a bit philosophical now and then, feel free to skip those parts.

What am I doing right now? I'm a Technical Analyst/Projectleader at Dolmen, a belgian software company. For the last few years, I've primarily focused on such areas as ASP.Net, Design Patterns, UML and BizTalk 2002 and 2004. Recently, Sharepoint 2003 has entered that list, and thats what I'm currently using the most.

I consider myself a generalist, meaning that I don't blindly focus on one technology, which - in my opinion - is not really possible anymore, since (for example) to know SharePoint you need at least a solid base of ASP.NET and Web UserControls knowledge (try making a Web Part without it...). Of course, its completely impossible to know everything about all products from the Microsoft family, so a little bit of specialization automatically occurs.

In the end, being a software guy is not about how good you are in certain technologies, what is important is your ability to adapt to new environments and products. With the current rate of new products/platforms/frameworks/whatever, by the time you 'dig' something completely, the RC1 of the next version usually rolls around the horizon anyway ;) So adaptability and flexibility are key. All of this is of course IMHO, allthough you can probably drop the 'H' :D

Anyhow, that was rambling number 1.

Sam