But it was Publius Cornelius Tacitus, the sharpest Roman historian of them all, who hit the nail on the head. In the introduction to his book that would include an account of the reign of Domitian (the notorious fly-stabber), Tacitus reflected on how best to analyse tyranny. It's problematic, he wrote, because it's very hard to find out the truth.
The temptation is to go one of two ways - total adulation for the tyrant's achievements or blanket vilification of his crimes. Readers, he went on, distrust adulation. It looks like flattery. They tend to trust vilification, as criticism appears more objective. But that doesn't mean, he warns, that it is necessarily right.
<<<
What i know is that there are not just 5 Design principles. There are almost 10 Design principles.
1. Open Closed Principle
2. Liskov Substitution Principle
3. Dependency Inversion Principle
4. Interface segregation Principle
ie SOLID + Component:
5. Release Reuse Equivalency Principle
6. Common Closure Principle
7. Common Reuse Principle
8. Acyclic Dependencies Principle
9. Stable Dependencies Principle
10. Stable Abstraction Principle
For sort description please see http://geekswithblogs.net/ramkinkarpandey/archive/2009/10/03/how-to-write-a-good-code-again.aspx
For detail please see www.objectmentor.com (Robert C. Martin)
>>>
Guess RRADCCRSDSA… is not a good acronym…hum…
Still smiling from having read Tony’s coinage of the JUDAS (JUst do Any Shit) acronymn as an antipattern, I found a very good post regarding the INVEST acronym as a guideline for laying out stories:
- Independent – i.e. Untangled description of the goal. Low Coupling.
- Negotiable – the story has to capture the gist, not mired down in details, and allows for growth as knowledge increases.
- Valuable – the story has to be valuable to the end user.
- Estimable – Estimate the effort so that the customer can prioritize
- Small – High Cohesion…
- Testable – A test can be written to prove that the story is achieved.
http://agileplusplus.blogspot.com/2008/09/invest-in-good-stories-and-smart-tasks.html
http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Shivonne once asked me how we/I store info regarding projects, related to code only.
I told her I am a firm disbeliever in MOSS – especially for developers.
I told her that I like keeping dev notes – not architectural documents (that’s different and does need to be kept in MOSS so that other stake holders can get to it) – in the source code, where it will be used the most.
That said, in return for the immediacy of finding info where I would need it most, one gives up formatting. Or any kind of protocol. It’s a free for all….
So I often come back to using a wiki.
But then we come across the notion of security. Most enterprises are a tad nervous (as is totally against) using online services for the documentation. Fair enough…
So…we get back to using a wiki…
….MOSS. Groan.
Then this weekend I just found http://www.tiddlywiki.com/
Interesting…
Quirky. A bit scary the concept of an app written totally in JScript… and only seems to work well in IE. I like it…in a weird perverse way.
I like the term too: GuerillaWiki…
Thoughts?
Not exactly what I would suggest – but I frankly get tired of remembering the different ways of registering services when I am writing Spikes. Some days it’s Unity, some days it’s Ninject, etc.
So I wrote the following (unoptimized, but still) wrapper that uses Reflection to not cause dependencies.
As for optimisation – I didn’t spend a lot of time thinking about it as I use IoC’s almost solely for Services, which means they happen only once in the lifecycle of a page of whatever. There are many many other areas to go optimize first.
Again - it’s fresh off the mint, so no idea if it will turn out to be that useful, but in case it’s useful to anyone else…
Binding done in Ninject using Reflection:
private void RegisterServiceByReflection<TInterface, TInstance>(object ioc, ServiceLifetimeType serviceLifetimeType)
{
string s = ioc.
GetType().FullName;
var o = ioc.InvokeMethod("Bind", new[] { typeof(Type) }, new[] { typeof(TInterface) });
var o2 = o.InvokeMethod("To", new[] { typeof(Type) }, new[] { typeof(TInstance) });
switch (serviceLifetimeType)
{
case ServiceLifetimeType.OnDemand:
o2.InvokeMethod("InTransientScope", null);
break;
case ServiceLifetimeType.Singleton:
o2.InvokeMethod("InSingletonScope", null);
break;
case ServiceLifetimeType.SingletonPerThread:
o2.InvokeMethod("InThreadScope", null);
break;
default:
throw new ArgumentOutOfRangeException("serviceLifetimeType");
}
}
Binding done in Unity, via Reflection:
private static void RegisterServiceInUnityByReflection<TInterface, TInstance>(object ioc, ServiceLifetimeType serviceLifetimeType)
{
Assembly assembly = ioc.GetType().Assembly;
//"Microsoft.Practices.Unity, Version=2.1.505.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35";
Type abstractLifetimeManagerType = assembly.GetType("Microsoft.Practices.Unity.LifetimeManager");
Type lifetimeManagerType;
switch (serviceLifetimeType)
{
case ServiceLifetimeType.SingletonPerThread:
lifetimeManagerType = assembly.GetType("Microsoft.Practices.Unity.PerThreadLifetimeManager");
break;
case ServiceLifetimeType.Singleton:
lifetimeManagerType = assembly.GetType("Microsoft.Practices.Unity.ContainerControlledLifetimeManager");
break;
case ServiceLifetimeType.OnDemand:
lifetimeManagerType = assembly.GetType("Microsoft.Practices.Unity.TransientLifetimeManager");
break;
default:
throw new ArgumentOutOfRangeException("serviceLifetimeType");
}
object lifetimeManager = Activator.CreateInstance(lifetimeManagerType);
Type injectionMemberType =assembly.GetType("Microsoft.Practices.Unity.InjectionMember[]");
object injectionMember = Activator.CreateInstance(injectionMemberType, new object[] {0});
//Use ExtensionMethod:
ioc.InvokeMethod(
"RegisterType",
new[]
{
typeof (Type), typeof (Type), typeof (string), abstractLifetimeManagerType, injectionMemberType
},
new[] {typeof (TInterface), typeof (TInstance), string.Empty, lifetimeManager, injectionMember}
);
}
Oh no…Just came across this:
The Microsoft.Practices.Unity.UnityServiceLocator class cannot be used under the WinRT profile because the CommonServiceLocator cannot be used under the WinRT profile currently.
That does not bode well for me…hope they figure it out right quick!
Link: http://unity.codeplex.com/releases/view/75719