Onenote needs a password to your skydrive account error (0xE0000024)

Skip this post unless you're having a problem where onenote starts asking for the password to your skydrive account.  Solution copied from here.



Onenote is my digital brain, and like my real brain sometimes it gets confused :) For example, twice onenote has said the password to my skydrive account is invalid(*), and refused to allow me to re-enter the password, making onenote effectively useless.



The fix in Windows 8 for when this happens again:

 Search -> Settings -> Credentials.

 Select - MicrosoftOffice15_Data....

 Remove



Restart onenote, and you'll now be able to enter your account password.



(*) I think the thing corrupting my credentials is moving time on my machine into the future.

Cool Tools: Recuva (File Undelete)

I'm not sure what I did wrong, but before I knew it I'd erased all the photo's on my camera's SD  card before the files were copied to my machine. After several seconds of swearing, and several minutes of panic, I realized there must be an undelete app. I found a free one, and it worked like a charm.



The undelete app is called Recuva,  it's free, and it worked like a charm to recover my erased files.  A  tip for you, when installing this app be sure to unclick "install bloatware" which is bundled with this recovery tool.

Performance impact of sorted arrays.

Computer performance is filled with unexpected results. This morning on  stack overflow I found  such a result, and decided to replicate it in C#.



Take an array of random integers and sum only the big integers.  Next, sort the array and re-sum the big integers. Does sorting the array affect the time taken to compute the aggregation? Let's code it up:



The results:




Wow, it's 5 times faster to perform this sum over a sorted array then an unsorted array. What's going on? Branch prediction!  If you've never heard of branch prediction check out the stack overflow answer that inspired this post.



You can quickly replicate this experiment using LinqPad and MeasureIt.Net, by loading this file.

Getting Caller Information in C# without reflection (AKA: __LINE__ and __FILE__)

When writing tracing code it's very useful to know your caller. If you've used C or C++ you likely combined macro's,  __LINE__  and __FILE__ to implement this capability.



In C# 4.5 there is a better way to solve this problem. By adding attributed function parameters you can instruct the compiler to have your callers supply their calling information.  The code (full source @ bitbucket):

 
     public static void TraceMessage(string message,
                [CallerMemberName] string memberName = "",
                [CallerFilePath] string sourceFilePath = "",
                [CallerLineNumber] int sourceLineNumber = 0)
        {
            Console.WriteLine("message: " + message);
            Console.WriteLine("member name: " + memberName);
            Console.WriteLine("source file path: " + sourceFilePath);
            Console.WriteLine("source line number: " + sourceLineNumber);
        }
        
        static void Main(string[] args)
        {
            TraceMessage("Hi");
        }

Which provides the output:

PS C:\hgs\ig2600_blog\CallerInformation\bin\Debug> .\CallerInformation.exe
message: Hi
member name: Main
source file path: c:\hgs\ig2600_blog\CallerInformation\Program.cs
source line number: 27
PS C:\hgs\ig2600_blog\CallerInformation\bin\Debug>

For those who like to peek behind the curtain, this feature is implemented by having the compiler add the calling information to the call site, which we see from the IL:

.method private hidebysig static 
    void Main (
        string[] args
    ) cil managed 
{
    .entrypoint
    IL_0000: nop
    IL_0001: ldstr "Hi"
    IL_0006: ldstr "Main"
    IL_000b: ldstr "c:\\hgs\\ig2600_blog\\CallerInformation\\Program.cs"
    IL_0010: ldc.i4.s 27
    IL_0012: call void CallerInformation.Program::TraceMessage(string,  string,  string,  int32)
    IL_0017: nop
    IL_0018: ret
}

Cool Tools: Text to UML

I've replaced all these tools with the much simpler plant UML:



http://plantuml.com/

Diagram Type	Input Text	Output Diagram
Simple Sequence	title Easy to draw Sequence Diagrams Smart Fellow-> Igor's Blog: Read Smarter Fellow-> Igor's Blog: Read Smarter Fellow->Igor's Blog: Leave Comment
Class Activity Use Case	[Person|Weight|Speak();Walk()] [Person]^-[Igor|FunnySocks|Juggle()]

For more complex sequence diagrams I recommend SDEdit.

DevPreview: Agile Principles Patterns and Practices Part2 II: Agile Design Principles

This post is in devpreview - skip if you're not passionate about this topic, leave comments if you are. 

I read lots, and
often forget what I wrote about.  To help
me remember, I’m going to take notes on my blog. Feel free to discuss what
you've seen in the comments.

Terminology

Term	Definition
Entity	The "thing" to which principles are applied.
Client	An entity which consumes this entity .
Dependent	The entity on which this entity depends to function.

Summary
of Principles

At 10,000 feet, design principles ensure that changes to a software entity, due to bugs or requirement changes,  have minimal impact on clients. 

Principle	Elevator Pitch
SRP: Single Responsibility	Entities should have one and only one reason to change.
OCP: Open Closed	Entities should be closed to changes, but open to extension
LSP: Liskov Substitution	Derived entity must be "substitutable" for the base entity in all regards.
DIP: Dependency Inversion	An entity should define the interfaces it requires of dependents.
ISP: Interface Segregation	An entity who provides functionality for multiple types of clients should expose that functionality via multiple interfaces.

SRP:
Single Responsibility Principle

An entity should
have a single responsibility. This can be tested if the entity can only require
change for a single reason.

You need to use it if:

You're changing your
entity for multiple reasons (e.g. how the objects are drawn, how the objects
are persisted)

Required
Because Traditionally

We lumped lots of
functionality into one big object.

You're
over doing it if:

You've created
separate classes which have never required changes.

OCP:
Open Closed Principle

Changes should only occur at predefined extension points.

You're
need to use it if:

Every time you
change your software, the changes are all through lots of the code.

Required
Because Traditionally

We didn't think
about where software would require flexibility.

You're
over doing it if:

You have extension
points that have only a single implementation.

LSP:
Liskov Substitution Principle

Derived entity must
be "substitutable" for the base entity in all regards.

You need to use it if:

Derived classes
break existing functionality.

Required
Because Traditionally

Derived entities
implemented "is-a" from a structural perspective. Inheritance needs
to be "is-a" from a behavioral point of you - more appropriately
named "acts-as".

Example
Violation:

Square deriving from
rectangle. Square is-a rectangle structurally, but no be behaviorally.  We can't substitute a square for a rectangle
for example, for a rectangle - rect.Height = 3; rect.Width=7; assert(rect.Height
==3) is not true for a square.

Notes

The "key"
for my understanding of this principle is that the invariants break on the base
class, not on the derived class. AKA a Square can be accessed as a rectangle,
but a rectangle cannot be access as a square.

IS-A is behavioral,
not structural!  The better English word
for this is can be substituted, or acts-as.

Unit tests against
the base class will often catch LSP violations.

Another way to catch
these is with pre and post conditions on base classes.

You're
over doing it if:

I don't think you
can over due this principle.

DIP:
Dependency Inversion Principle

Entities should
provide interfaces for their dependents to implement.

You need to use it if:

Your entities
require changes when your dependents change.

Required
Because Traditionally

We implemented
entities directly on the implementations exposed by their dependents.

You're
over doing it if:

You're creating
interfaces for well baked objects in the base classes (e.g. String) and your
software   will not be used cross
platform.

Notes

This is called
inversion, as traditionally, entities simply consumed the implementation
provided by their dependents.  If I had
my druthers would be called "dependency specification".

At the core:

• No variable should hold a ref
  to a concrete class


• No class should derive from a
  concrete class


• No class should override an
  implemented base class method

ISP:
The interface segregation principle

A class can
implement many interfaces, but each interface is cohesive!

You need to use it if:

The interfaces do
not ad-here to the SRP principle.

Required
Because Traditionally

We used to create
interfaces that didn't match individual behavior, but instead created
interfaces to represent an implemented class.

You're
over doing it if:

You have a bunch of
single method interfaces.

Notes:

Clients should not
be forced to depend on a method they do not need.

Fat classes are OK,
but fat interfaces are not

Two separation
methods:

1. Multiple inheritance of
   interface


2. Use an adapter to convert
   from type 1 to type 2 (Add example)

Even when a client
depends on two interfaces implemented by the same class, specify the dependency
as two interfaces.

If you expose two
interfaces with similar functionality, repeat the duplication in the
interfaces.  Recall the interfaces will
be used by independent clients, and you don't want to force a change in a
client if their needs have not changed.

Duck typing in C#

There are two types of typing, static and dynamic (also known as duck). In Static typing systems you specify the type at compile time and if your program accesses a field not declared in your type, you get a handy compiler error. By contrast in dynamic typing systems a  type is never specified, and can't be validated at compile time. Thus errors are caught as runtime exceptions.



If dynamic typing is error prone, why would you want to use it? As usual, you'd want to use it because it provides  extra power. For example, imagine you have a list of several objects that implement Quack(). How can you call  Quack on all objects that support it?

class Dog
{
 public string Quack() {return "Bark";}
}

class Cat
{
 public string Quack() {return "Meow";}
}

class Mouse
{}

var animals = new List<object>() {new Dog(), new Cat(), new Mouse()};

If you've only used static languages, you'd think you need to add an interface IDuck{string Quack();}, and then change Dog and Cat to inherit from IDuck.  Knowing about design patterns, you might prefer to create an adapter to convert to a class that implements IDuck.  On the other hand, if you've used dynamic languages, you don't care. Instead of adding an interface, you use Duck Typing.  Duck typing gets it's name from the old adage - if it walks like a duck, and talks like a duck,  it's a duck.  C#4.0 added the duck typing feature which you can unlock via the dynamic type.  You can solve our earlier problem problem of collecting quackers like so:

var ducks = animals
// Enter the dynamic type system.
.Cast<dynamic>()
// Remove objects that can't quack
.Where(x=>x.GetType().GetMember("Quack").Length > 0 )
// return to the static type system.
.Select(x=>new {Quack = x.Quack()});

// Write the different quacks to the console.
foreach(var d in ducks) Console.WriteLine(d.Quack);

There you have it - duck typing is a powerful way to interact with your objects. Iin C# 4.0 you can mix C#'s safe static typing with the powerful, yet dangerous so use sparingly, duck typing system.