class Program
{
public delegate void Say(string s);
public void Hello(string s)
{
Console.WriteLine("Hello " + s);
}
public void Goodbye(string s)
{
Console.WriteLine("Bye bye " + s);
}
static void Main(string[] args)
{
Program obj = new Program();
Say a = new Say(obj.Hello);
Say b = new Say(obj.Goodbye);
a("Johnson");
b("Johnson");
}
}
Thursday, September 1, 2011
Saturday, September 25, 2010
Sleep until
long current = DateTime.Now.Ticks; long start = DateTime.Parse(ConfigurationManager.AppSettings["StartDateTime"]).Ticks; long timeout = TimeSpan.Parse(ConfigurationManager.AppSettings["Timeout"]).Ticks; long sleep; if (current < start) // until next timeout sleep = timeout - ((current % timeout)) + (start % timeout); else sleep = start - current; Thread.Sleep(new TimeSpan(sleep));
Wednesday, August 25, 2010
Note to self
In the context of programming
- Less code is more code
- Less code is in my experience usually better code
- Less is easy, pretty (pretty easy)
- Less doesn't need to be simple
- Simple doesn't need to be less
- Simple isn't bad!
- Fancy code doesn't necessarily need to be simple nor less
- Many steps doesn't need to be complicated or bad, but make sure you document it
- Don't over-engineer!
- Documentation is important but it is more important to be documenting
- Keep your documentation up to date, use a wiki
- Code should be self documenting
- You can't document everything
- Readability is very important
- Trust your instincts
- Structure and organisation is very important
- Always insist on using a english platform when as developer, useful when:
- creating screenshots you want to send to another country
- searching for error messages on line
- learning keyboard shortcuts
Wednesday, August 18, 2010
Design problems in our view model?
The following code is found in the view model. An object is serialized, marked exported and persisted to the repository.
There might be a problem with this function that I want to discuss a little. There is also an ExportAll method which iterates through all items not exported and persists that to the database.
As you probably already noticed there are no mechanics in the Export functionality that captures the fact that the item is already exported before it saves it. That means that you can select any item and re-export it any time you like, even after you've done changes to the item.
But in my opinion this is just weird behavior and a recipe for disaster since
Also this code is found in the view model and a RelayCommand is instantiated so that we can use this code in the xaml view. But what if we want to use this code somewhere outside of this view? Another service. Shouldn't this logic be deeper and available at a lower more common level?
If I do changes to the logic in this method the changes will only be valid in the view model, but maybe this is ok? I hoping that I'm not creating technical debt in doing modifications to this method to throw exception when trying to commit data to the repository when trying to export items already having been exported.
private void Export(object obj) { var item = obj as IItem; _itemSerializer.CreateCustomerItemXML(item); item.IsExported = true; _repository.Save(item); }
There might be a problem with this function that I want to discuss a little. There is also an ExportAll method which iterates through all items not exported and persists that to the database.
As you probably already noticed there are no mechanics in the Export functionality that captures the fact that the item is already exported before it saves it. That means that you can select any item and re-export it any time you like, even after you've done changes to the item.
But in my opinion this is just weird behavior and a recipe for disaster since
- If you edit an item and invoke ExportAll the edited item updated but not exported.
- If you edit an item and invoke Export the edited item overwrites the existing data.
Also this code is found in the view model and a RelayCommand is instantiated so that we can use this code in the xaml view. But what if we want to use this code somewhere outside of this view? Another service. Shouldn't this logic be deeper and available at a lower more common level?
If I do changes to the logic in this method the changes will only be valid in the view model, but maybe this is ok? I hoping that I'm not creating technical debt in doing modifications to this method to throw exception when trying to commit data to the repository when trying to export items already having been exported.
Friday, August 13, 2010
Hello World with Microsoft Unity framework
Inversion of Control, dependency injection is achieved with the Microsoft Unity Framework. It is a nice framework for making loosely coupled applications.
Add the following references to your project after having installed the Unity application block.
And then include the following using statement in your code:
The Hello World program:
What's going on above?
1. Define the interface
2. Make a implementation
3.Bootstrapping: register your interface to any interface implementation
4. Resolving what class is registered with what interface, invoke your code
5. Resolve what class is associated with our interface. This is how you run/start your class.
6. And you're ready to print hello, world. Of course you don't need to return a property. You could have done the console writing inside your implementation of the interface.
Add the following references to your project after having installed the Unity application block.
--> Microsoft.Practices.ObjectBuilder2 --> Microsoft.Practices.Unity --> Microsoft.Practices.Unity.Configuration --> Microsoft.Practices.Unity.Interception --> Microsoft.Practices.Unity.Interception.Configuration --> Microsoft.Practices.Unity.StaticFactory
And then include the following using statement in your code:
using Microsoft.Practices.Unity;
The Hello World program:
using System; using Microsoft.Practices.Unity; public interface IHelloWorld { string Text { get; } } public class HelloWorld : IHelloWorld { public string Text { get { return "Hello, World"; } } } class Program { static void Main(string[] args) { // Bootstrapping IUnityContainer unityContainer = new UnityContainer(); unityContainer.RegisterType<IHelloWorld, HelloWorld>(); // Resolving what class is registered with what interface var obj = unityContainer.Resolve<IHelloWorld>(); Console.WriteLine(obj.Text); } }
What's going on above?
1. Define the interface
public interface IHelloWorld
2. Make a implementation
public class HelloWorld : IHelloWorld
3.Bootstrapping: register your interface to any interface implementation
IUnityContainer unityContainer = new UnityContainer(); unityContainer.RegisterType<IHelloWorld, HelloWorld>();
4. Resolving what class is registered with what interface, invoke your code
var obj = unityContainer.Resolve<IHelloWorld>();
5. Resolve what class is associated with our interface. This is how you run/start your class.
var obj = unityContainer.Resolve<IHelloWorld>();
6. And you're ready to print hello, world. Of course you don't need to return a property. You could have done the console writing inside your implementation of the interface.
Console.WriteLine(obj.Text);
Subscribe to:
Posts (Atom)