ErricGu just posted about the role of a project manager in an agile environment.
the person who takes that role needs to be mindful of that and willing to push any decisions that rise up back down to the time. If the person has previous experience (and a preference) for “being in charge”, they are unlikely to do a good job in that role.
Maybe I'll point Ralph (my imaginary manager from hell) to this post next time I encounter one.
FolderShare and SkyDrive come from the same team (the original guys that were bought by microsoft). SkyDrive has support for feeds.
The Microsoft Sync framework supports synchronization through syncfeed.
See where I'm going with this?
An interesting issue was recently raised against my rest framework. The following URI template was used to access a fictional customer:
/customer/{customerName}
When generating an email pointing to this customer, another part of the system was adding the following url:
http://example.org/customer/john+doe
At this point, my framework returned a 404, even though John Doe exists in our database. So what is happening there? When setting a breakpoint on my CustomerHandler.Get(string customerName) method, customerName ended up with the plus sign present. Why wasn't it converted to a space? Here's some PowerShell code to demonstrate. First, let's create a Uri object and see the result.
59> [System.Uri]"http://example.org/folder with space" | select absolutepath, absoluteuri,originalstring | fl
AbsolutePath : /folder%20with%20space
AbsoluteUri : http://example.org/folder%20with%20space
OriginalString : http://example.org/folder with space
As you can see, the space is encoded with a %20... Now let's see what happens if I call HttpUtility.UrlEncode.
61> [System.Reflection.Assembly]::LoadWithPartialName("System.Web") | out-null
62> [System.Web.HttpUtility]::UrlEncode("folder with space")
folder+with+space
Now the space has been replaced with a plus. Let's review the msdn documentation for the UrlEncode method.
If characters such as blanks and punctuation are passed in an HTTP stream, they might be misinterpreted at the receiving end. URL encoding converts characters that are not allowed in a URL into character-entity equivalents; URL decoding reverses the encoding. For example, when embedded in a block of text to be transmitted in a URL, the characters < and > are encoded as %3c and %3e.
Obviously the documentation doesn't really described the behaviour that we experience. So is a URL encoding within the scope of the http protocol supposed to have a + or a %20? Who's right and who's wrong?
Let's travel together along the spec stack we use when dealing with html content, and find out who, between Uri and UrlEncode, is right.
This specification covers URLs in their generalized form, and that's teh specification that defines percent encoding of url, where any reserved character have to be encoded as a percent sign followed by the two-letters hexadecimal representation of the codepoint.
This actually would imply that the correct encoding form of the URL should be http://example.org/customer/john%20doe.
It also specify that the plus sign is a reserved character, one that can be used by a scheme to delimit stuff. Defining what that stuff is should be the scheme's responsibility. The scheme here is http, so we switch to the next spec in our stack.
This specification, even though it's been written earlier than the lastest URI, does specify some scheme-specific information on how URLs work and what they represent. Going through that specification, HTTP defines some specific behavior for Uri, for example that http://example.org, http://example.org:80 and http://example.org/ are all equivalent.
The specification also mention the equivalence of the percent encoding we've already seen. Still nothing about the plus sign. Which leads us to the third specification that's involved here.
Note that I ignore the XHTML 1.0 specification as it is mostly only a reformulation of the html 4 specification in an xml format.
The HTML specification reminds the reader of URIs and how they work. There are two interesting bits in the specification. The first one, entitled non-ascii characters in URI attribute values, defines once again the percent encoding scheme. Still no trace of that plus sign.
And then you discover the gem of the application/x-www-form-urlencoded content type. In it, we find the usual url encoding, with the addition of the space being encoded as a plus.
Interestingly enough, this format is only to be used when attaching content within a POST http request, and has nothing to do with URL encoding, except for the similarity of writing key=value&key2=othervalue to encode named values.
So there you have it. The content-type used by html to send form content is an html specific content sent as the payload to a post http request. It has no bearing and no compatibility with either http or URLs. If you generate or consume URLs, the plus sign should be opaque.
In other words, stay welll away from HttpUtility.UrlEncode.
Seen this morning:
The Windows Experience Blog : Announcing Windows Live FolderShare Beta Refresh for PC-to-PC Sync
That team, bought by Microsoft, has been busy building Windows Live SkyDrive, now they update FolderShare... Maybe, just maybe, this team will finally deliver a unified experience for remote sync and file access. And maybe integrate with my Windows Home Server box...
[Update: oh well, this was unnecessary. I'd rather people understood the meaning of quiet zone and weren't so up their own a*se. And personal recorders are so over-used. Is it that hard to just write?]
Last night, I've made some progress towards my long-overdue MVP series of articles, by rewriting what I had to adopt the same format as the presentation I did yesterday at the London .net user group.
As promised, here's the code from last night. Stay tuned for the articles.
Thanks to the surprisingly large audience, and thanks to those that came to me to say they were reading this blog. I still get quite shocked when people tell me they saw a specific article I've written.
To be fair I still get shocked when people remember my name the second time they see me, as I'm sadly quite the opposite and have a lot of trouble remembering people by name.
Anyway, enjoy the code in its roughest form, nearly no comments in there, and still no powerpoint slides :)
For the masochists amongst you, two tips when installing Vista 64bits on a MacBook Air:
And now some pictures of the unboxing.
The full installation from boot to first screen (including me typing the product key) came at a whopping 32 minutes. I'm so impressed with how snappy everything feels that I'm thinking of either replacing my main drive on the MacBook Pro by a Solid state drive (as soon as a 128G gets out) or just doing my development on the MacBook Air!
A bit of CLI love (and I'm sure my readers will correct me fairly quickly with something much smaller and better!), for those like me that wish they never had to use tortoise.
Adding all files that are not in the repository
svn st | %{ if ($_ -match "\?\s+(.*)") { svn add $matches[1] } }
Removing the dreaded bin and obj folders if you did an add by accident
ls -i bin,obj -recurse | % { svn revert $_ -R }
And to exclude all the stuff you put in your .svnignore (and that one works with any shell)
svn propset svn:external . -F .svnignore -R
Enjoy!
I got used to use the menu system with the keyboard to compensate for the trackpad on my macbook pro not having a usable right click (the double tap behavior is erratic at best and unusable). Shift-F10 is going to make my life so much easier!
[Update: I just realized this shortcut works for any application. I should really increase my keyboard shortcut proficiency, especially as I don't seem to have enough space for my mouse anymore in the office...]
[Started updating the previous entry, but the reply is chunky enough to go in its own post]
One person on the dotnet-clr mailing list has highlighted, quite accurately, that the RaiseXxxEvent method should really take EventArgs as a parameter instead of a string to ensure it can be swapped with a class inheriting from EventArgs. If you want that kind of extensibility, then yes, put an EventArgs as a parameter. I should update the sample.
A second person in the comments vehemently disagree with my point, so let's go for a simple rebuttal, as I do not believe the arguments to be accurate.
The first part is that the pattern, to be deemed acceptable, should be OnXxx(object src, EventArgs ea). I have nothing else to say but to point with every single of my examples as none of them seems to "get" the right way of declaring OnXxx. As for this way to be the right way, I've not found any other reference to support Peter's argument.
The Design Guidelines for Developing Class Libraries does mention the void delegateType(object source, eventargs e) signature for event handlers, not for event raisers. As for event raisers, here's a big quote from the same source.
Do use a protected virtual method to raise each event. This is applicable only to non-static events on unsealed classes, not to structures, sealed classes, or static events.
Complying with this guideline allows derived classes to handle a base class event by overriding the protected method. The name of the protected virtual (Overridable in Visual Basic) method should be the same as the event name prefixed with On. For example, the protected virtual method for an event named "TimeChanged" is named "OnTimeChanged".
Important Note:
Derived classes that override the protected virtual method are not required to call the base class implementation. The base class must continue to work correctly even if its implementation is not called.
Do use a parameter that is typed as the event argument class to the protected method that raises an event. The parameter should be named e.
Let's see:
Indeed, the second part talks about passing a string instead of an EventArg, this came from typing quickly an example rather than the focus of the pattern, but point taken and resolved.
The third part is interesting. The reader is oblivious to the fact that the event raising method is called RaiseXxxEvent. Missing the italics is an easy mistake to make so let's move on. Apparently OnClear is a rat hole because it doesn't follow the right pattern (neither do the others as said before, and worst, neither does the design guideline...) OnClear with any other argument can mean anything but OnClear(object, EventArgs) can only mean one thing. So in this case, using On can have several meanings and it's fine, but in the case of Raise, you may never know if someone cannot confuse RaiseTheMountain and RaiseGoingUpEvent, so it's not acceptable. I'll assume the whole diatribe is based on the EventArgs confusion and the use of a string, and the missing Event suffix, so I think the point is clear.
So I'll summarize the argument I made extensively: OnXxx is implemented widely but implemented widely wrongly across mscorlib, asp.net, winforms and WPF. It has a double meaning as either raising (as per the design guidelines) or handling (as per people's use of it). The examples in the previous post show that without . Furthermore, the asp.net language use OnXxx to autowire events to event handlers, just like html events.
The confusion is enough that I choose to split the pattern in two methods with clear intent: HandleXEvent to handle an event, RaiseXEvent to raise an event. And even by doing so, I still adhere to the design guidelines issued by Microsoft. If you find this more confusing than OnXxx, I'm just lost for words.
[Updated the code sample for the raising event method. See my response to the comments that were made.]
Some people, like Jeremy, really don't like events. I have to admit having a nearly-fanatic interest in good event patterns. One of such patterns I've seen used and misused continuously is the OnXxx pattern. Let's have a quick look at what the MSDN gods have to say about this.
You raise the event by calling the protected OnEventName method in the class that defined the event, or in a derived class. The OnEventName method raises the event by invoking the delegates, passing in any event-specific data. The delegate methods for the event can perform actions for the event or process the event-specific data.
Note:
The protected OnEventName method also allows derived classes to override the event without attaching a delegate to it. A derived class must always call the OnEventName method of the base class to ensure that registered delegates receive the event.When you want to handle events raised in another class, you add delegate methods to the event.
So far so good. Let's open reflector and check how well is this pattern implemented. First candidate (selected through my advanced AI randomisation algorythm called click until you find a class with an OnXxx patern), FileSystemWatcher.
protected void OnChanged(FileSystemEventArgs e)
{
FileSystemEventHandler onChangedHandler = this.onChangedHandler;
if (onChangedHandler != null)
{
if ((this.SynchronizingObject != null) && this.SynchronizingObject.InvokeRequired)
{
this.SynchronizingObject.BeginInvoke(onChangedHandler, new object[] { this, e });
}
else
{
onChangedHandler(this, e);
}
}
}
So far so good. Let's stay within mscorlib (just in case the pattern was team specific), and have a look at DictionaryBase.
protected virtual void OnClear()
{
}
Oh. Where's the event call? Let's see what the method is described as doing.
Performs additional custom processes before clearing the contents of the DictionaryBase instance.
Wait a second, I thought we were supposed to use OnXxx for raising events, not to change stuff. Ok, let's move on to the ado.net team, and have a look at DataSet, and for the same price I give you not one but two methods.
protected internal void RaisePropertyChanging(string name)
{
this.OnPropertyChanging(new PropertyChangedEventArgs(name));
}
protected virtual void OnPropertyChanging(PropertyChangedEventArgs pcevent)
{
if (this.onPropertyChangingDelegate != null)
{
this.onPropertyChangingDelegate(this, pcevent);
}
}
Alright... Now I'm getting quite confused. I can call RaiseXxx(name) which in turns call the proper OnXxx pattern that calls the event. This is now getting quite messy. Let's see what the guys in the asp.net team do with the DataSourceControl.
protected virtual void RaiseDataSourceChangedEvent(EventArgs e)
{
this.OnDataSourceChangedInternal(e);
this.OnDataSourceChanged(e);
}
Note that both OnXxx are now private methods... At least in DataSet you have two ways to do the same thing, one legal and one not legal (again, according to the msdn documentation). Not convinced yet? Ok, let's see what the Winforms guy have been doing and have a look at Control. I'll point to two examples.
[EditorBrowsable(EditorBrowsableState.Advanced)]
protected virtual void OnNotifyMessage(Message m)
{
}
And example 2.
[EditorBrowsable(EditorBrowsableState.Advanced)]
protected void RaisePaintEvent(object key, PaintEventArgs e)
{
PaintEventHandler handler = (PaintEventHandler)base.Events[EventPaint];
if (handler != null)
{
handler(this, e);
}
}
Note that the OnPaint event exists and does mostly the same thing. Isn't it great to have that much flexibility? Ok, last but not least, let's see what the latest greatest brings us with WPF's UIElement.
public void RaiseEvent(RoutedEventArgs e)
{
if (e == null)
{
throw new ArgumentNullException("e");
}
e.ClearUserInitiated();
this.RaiseEventImpl(e);
}
protected virtual void OnMouseLeave(MouseEventArgs e)
{
}
Can you make any sense of the OnXxx notation? No? Me neither, neither do my developers. So I hereby propose (again) to just get done with it already and *aknowledge* that OnXxx is an anti-pattern used either for raising or for handling events, is overused and misused, and should die a long and painful death. I propose the simpler and more semantically correct syntax:
public class DoingEventsProperly
{
public DoingEventsProperly()
{
this.SomethingChanged += HandleSomethingChangedEvent;
}
public event EventHandler<PropertyChangedEventArgs> SomethingChanged = (src, ea) => { };
protected virtual void RaiseSomethingChangedEvent(PropertyChangedEventArgs e) { SomethingChanged(this, e); }
protected virtual void HandleSomethingChangedEvent(object src, PropertyChangedEventArgs ea) { }
}
What this class achieves is covering all the scenarios we just encountered.
And it's also easy to explain: Call it Raise when you're Raising an event and call it Handle if you're handling an event. I think the semantic complexity is achievable.
I may go into the other patterns such as explicitly cancelable events for consumers and explicitly cancelable by contract for inheritance cancellation another day.
And remember: The best way to combat an anti-pattern is to stop using it.
[Updated: Toned down a few sentences as they were more emotional than necessary.]
I've been holding back from commenting as there's been a lot happening and I probably need a few more days before my mind is set, both on the technicalities we discussed, on the process, and on the ideas. For today I'll focus on the alt.net movement, and on the conference. I'l leave the technical stuff for later.
There's been strong suggestions that user groups are enough to cover the scope of alt.net. The concepts behind alt.net have been up for discussion, but by their nature, they need a small kernel of focused people discussing what is doable, what the state of affairs are and how to convince people to take the alternative route of innovation. We need people to challenge, and for that they need to have a forum in which they can progress and advance ideas.
The wider communities existing today seems to me a perfect place to distill those ideas, but maybe they're not the right place for defining them. Doing that necessitate people knowing about the subject, the technologies and the commercial realities to break the all <insert your favourite software vendor> approach. Only from those reflections can it be distilled to user groups, in the more typical presentation style that is common to those groups.
This conference had good less good sessions. The good sessions were the ones where people sat down and discussed in an open format each subject. Having Roy Osherove in a room discussing why mocks are not always a good idea and can lead to brittle tests, and question the constraints imposed on testing because of the first generation of mocking frameworks was fantastic. But what was fantastic was not having someone taking over the room to present his own agenda or switch the room into demonstration mode, where an individual does most of the talking. The spirit was very much a relaxed opened session where everyone contributed what they had to say.
The REST discussion was interesting, but dragged on longer than necessary. The discussion was very much focused on one presenter doing most of the talks, and I felt that by the time others had the opportunity to discuss their solutions, the room was tired, and people started leaving. To a certain extent I guess I can only blame myself for not having prepared material and moving the discussion more towards the points I was interested in, so I can't blame anyone, but it felt more like a presentation or an ask the expert session than the discussion that happened in other sessions.
Overall, I think the demonstrations that were done didn't add anything to the talk, as I do not believe most of the room saw the light of content type negotiation through yet another wiki demo. That said, I aplaud Alan for pushing this part of the HTTP spec, something that I've also been trying to get through for quite a few years. Other people had stuff to show and by then it was too late. Maybe those demonstrations should overall be discouraged to keep the focus on the discussion.
As for the ugly, in the becoming a better developer, the discussion became quite wide on the challenges we face. I discussed, maybe too much, a recent case where one of my clients revoked my contract for a wide range of reasons. I highlighted the fact, during that session, that having a forum where developers can explain their worst experiences, share them with others, is probably a good idea to relief that feeling you get that you're the only one it happened to. Getting fired or being the scapegoat on a project happened to most contractors. Hence why the suggestion was made that maybe AA-like meetings for us guys to talk about the struggles we face in a safe haven would be good therapy.
The issue there is that maybe some people have over-inflated egos and refuse to talk about it, because it would tarnish their carefully crafted image. I assumed this session was a safe haven into which I could have those kind of discussions, without fearing consequences.
Only a few hours later at the pub, we were discussing my inbox email filtering policy. I may blog about it in more details later on, but I filter email based on recipients, to/cc lists, if its a reply or not, and split those incoming emails in sub folders. The lowest priority I read when I have time at the end of the day, the medium is read when i have time (usually lunch), and only the very few emails getting straight to my inbox get read immediately and treated in a GTD way.
However, one of the person present during that session, I hope fuelled by the copious amount of beer that was consumed by all parties involved, saw fit to reply to me, after a couple of exchanges explaining that my email policy couldn't work, that my views on emails maybe were why I got fired. This is low. Furthermore, it made me wonder if that person had to resort to mentions of my previous failures because they ran out of arguments or because they were making a point. Maybe repeating the same thing three times is not an argument anyway. But more than that, this breaks the safe haven I talked about a few paragraphs earlier. Explaining my struggles with some clients should never come back to bite me back, especially not by an organizer that is supposed to help IT people deal with those issues.
I for one will know to avoid discussing those issues if I don't have the guarantee of a safe haven. I did express my complete dismay at his comments and that it was quite out of order, and got an apology for hurting my feelings. I accepted the apology even though my feelings in this matter are nearly as irrelevant as the comment that was made. Moving on.
Maybe the relevant point in all this is the reflection on why the situation got that bad. I think it may all come down to learning how to let go. Maybe as a contractor sometimes I should not push so hard when I see a project failing, and let it fail the way the manager wants it to fail. Maybe the constant push against decisions I deem bound to failure are not my place to take. Overall, when bad decisions are taken continuously, I should learn to quit and either get on with it, or more likely break my contract and find a client that wants to listen to what I have to say.
The question still pending is, what is the right forum to discuss failures? I find that contractors are especially frisky when talking about their mistakes and their failures, maybe by fear for their public image, or maybe because they've had the situation I just encountered and it hit them back. Who knows. It shouldn't be this complicated when we're all in the same boat. And personality conflicts are not going to help us much.
I'll focus on the technical discussions that happened as I try to remember them this week. There's been very good points raised that each should have their own entries, and the first will probably be about REST and my open implementation of UriTemplate for .net 2. I've learnt from others and their views, and have questioned my own views. I wish the conference would've spanned two days.
I'd like to thank the people that came, the organizers for their hard work (always nice to see Z and Ian, and I'm going to follow up on my promise to come to the london .net user group.) Thank to Conchango and Redgate (special mention to Michelle for always making sure I had a beer, for better or worse, and to Ben for such a lovely evening on Friday, and hope he recovered from that hangover). It's been a great experience.
My hotmail is back apparently... we'll never know what happened. At the alt.net conference this morning... Early start after a very late evening. There are damn smart people in here, very uplifting.
Here's the sessions I'm going to attend:
They're the bits I proposed in each of the topic-based subjects that are being grouped together...
It's my opinion that we should've had probably less topics proposed, and the decision on what stays and what doesn't should've been taken by the people that are here rather than pre-organized. It makes people passively vote for sessions with less self-organization. But maybe British people are just less proactive and expansive than our American counterparts.
[Update: Hotmail reactivated the account within 24 hours. I do like a bit of drama...]
My hotmail account has been suspended... If you've tried to reach me on seb@serialseb.com from this morning, I'm in the hands of some sort of automatic processing that believes I'm a spammer... My account has been closed!
Considering the only emails I send are to my family, my work and the alt.net community, and that's at most 20 emails a day, you start wondering what the heck is going on!
I'll keep you posted. If anyone is working at hotmail, a bit of help would be appreciated!
Oh well, I'll have some road stories for the alt.net conference in a few hours. For the Londoners see you there!
[Updated: Added reference to which classes were being used. The DataContractJsonSerializer is part of the .net 3.5 release.]
There's been a few discussions recently about the cost of using JSON against using Flash Remoting. Its a fact of life to have to discuss those issues when you work with a lot of Adobe people, especially when you're the Microsoft guys.
One of the discussions is around the performance of JSON and Flash Remoting. There is the BlazeBench application that would imply AMF wins hands down in every configuration. BlazeDS is a Java server that Adobe is apparently open-sourcing, but me being an asp.net guy, I wanted to see for myself what all this meant.
You see, in terms of architecture, you will always have a service layer, be it in the shape of a REST api, SOAP endpoints or a flash remoting object that pulls DTOs for display by the application. The difference between each of those solutions is going to be in the serialization mechanism you use. So I wrote a small application that compares the time it takes to serialize objects using the following:
I've not done anything special to optimise any scenario and the object graph is the same. I serialize 1,000, 10,000 and 100,000 graphs with each of the serializers, everything is built first before running the test, everything is serialized to a MemoryStream.
This is what i get.
The big surprise for me was the binary serialization using BinaryFormatter, which is nearly as slow as the XmlSerializer.
More important for this study, the serialization cost of the WCF JSON serializer is only 300 milliseconds, for 100,000 objects.
With those results in hand, I will argue that there is no real performance gaps between WCF JSON, Flash AMF and XML DataContracts. Even with the asp.net AJAX extensions JSON serializer, the cost of serializing your graph is probably going to be a fraction of the cost of retrieving such an object graph from a database.
If anyone wants the source code, I'll be more than happy to publish it, provided my client allows it.
[Update again]
As a reminder that my readers are usually much more skilled than I am, two anonymous commenter points out the obvious:
ii .
or
ii $pwd
Never thought of that. It's just beautiful. Thanks! The second commenter has been chatting with me through the messenger control, and points out that Start-Process is only available if you have PowerShell Commnity Extensions... A fact I missed completely. I stand twice corrected.
I've not blogged any PowerShell scripts for a while... I very often navigate around in PowerShell, but sometimes you want to switch to a graphical view. That's exactly what this script does (note it only works on the file system though...)
function Open-Explorer { Start-Process $(get-location) }
Enjoy!
Most of you have probably already tried using the source server support in vs2008 for the .net framework code ScottGu announced (it was, after all, 8 days ago...) In it, it's recommended to add a hotfix.
When you try installing it, you get an installation failed notification. If you view the report (generated as a local html document with scripts, running from the local drive, and as such with script deactivated by default, stupid thing number 1), you see the following:
Returning IDOK. INSTALLMESSAGE_ERROR [Error [1].An installation package for the product [2] cannot be found. Try the installation again using a valid copy of the installation package '[3]'.: 1706Microsoft Visual Studio 2008 Professional Edition - ENU]
As a guess, the valid copy of the installation package has the same name as the download from MSDN from which my copy of visual studio comes from. A message in the forums confirms the need for the physical media (or iso) to be present.
So there, my second award for software that sucks comes to the hotfix installer. Next time, a review on how badly the Hotmail outlook add-in sucks.
http://www.apple.com/macbookair/
Ordered. Because I need an ultra lightweight to test the battery life and solid state drive implications for Windows development. And because I had to. Tried resisting all week, and today I failed.
This is something that we had to discover with reflector when I wrote the Excel-like control we used for the National Express WPF application, so it's good to see people writing about it, especially when it's Charles Petzold in msdn magazine.
An additional thing you might want to do is have properties defining the templates for different sub-elements used by defining a dependency property of type DataTemplate. You may also want to create new sub-controls, e.g. a CellPresenter, that you can add to the template to define where in the template other components of your control will get injected.
That should probably be an article in its own right. Maybe this weekend if I recover from my sore throat.
CaffeineIT.ShoppingList.zip