- Open the folder in the skydrive site using the browser (it would be under Shared menu on the left). The url will look something like: https://skydrive.live.com/?cid=529BD9445B66F60D&id=529BD9445B66F60D%21189#cid=529BD9445B66F60D&id=529BD9445B66F60D%21189. Now the “cid” query parameter in the URL.
- Right-click on Network (in windows explorer), then “Map Network Drive”
- Specify Folder as: https://d.docs.live.net/[cid]/[folder_name]. For the sample URL above, it would be https://d.docs.live.net/529bd9445b66f60d/CQRS (note the folder name isn’t in the URL, you need to know it beforehand, and it has to match what it’s named on the site).
- Check the “Use alternate credentials” option in the dialog:
- Click Finish. Enter your Live ID credentials when asked. Done!
Not everything works that great (i.e. copying large files via drag&drop doesn’t work, renaming folders, etc., at least in my experience), but it’s pretty darn convenient most of the time. I’m not sure the same thing works for your own personal folders. I don’t use SkyDrive at all, but it certainly does for shared ones (nice when you need a simple way to share docs within a team, privately and without requiring any software to be installed for syncing…)....
Read full article
Currently in the .NET world, most OSS projects are available via a NuGet package. Users have a very easy path towards *using* the project right away.
But let’s say they encounter some isssue (maybe a bug, maybe a potential improvement) with the library. At this point, going from user to contributor (of a fix, or a good bug repro or even a spike for a new feature) is a very steep and non trivial multi-step process of registering with some open source hosting site (codeplex, github, bitbucket, etc.), learning how to grab the latest sources, build the project, formulate a patch (or fork the code), learn the source control software they use (mercurial, git, svn, tfs), install whatever tools are needed for it, read about the contributors workflow for the project (do you fork & send pull requests? do you just send a patch file? do you just send a snippet? a unit test? etc.), and on, and on, and on. Granted, you may be lucky and already know the source control system the project uses, but in really, I’d say the chances are pretty low. I believe most developers *using* OSS are far from familiar with them, much less with contributing back to various projects. We OSS devs like to be on the cutting edge all the time, ya’ know, always jumping on the new SCC system, the new hosting site, the new agile way of managing work items, bug tracking, code reviews, etc. etc. etc.. But most of our OSS users are largely the “...
Read full article
Say you have a class that needs to collaborate with another, say a repository:
public class OrderProcessor
{
public void ProcessPayment(Guid orderId, Payment payment)
{
using (var repo = new OrmRepository())
{
var order = repo.Find<Order>(orderId);
order.Pay(payment);
repo.Save(order);
}
}
}
Now that clearly is very hard to test ‘cause it’s directly instantiating the repository. So we know we have to refactor that and pass the repository instead, so that tests can replace the implementation and make assertions about the interaction (if we want to):
public class OrderProcessor
{
private OrmRepository repository;
public OrderProcessor(OrmRepository repository)
{
this.repository = repository;
}
public void ProcessPayment(Guid orderId, Payment payment)
{
var order = this.repository.Find<Order>(orderId);
order.Pay(payment);
this.repository.Save(order);
}
}...
Read full article