MVC podcast

by DotNetNerd 7. November 2009 12:24

About one year after I did my first podcast, which was about F#, the second has now been released on ANUG.dk. This time I am talking with Søren about MVC, and I think that in spite of some technical difficulties we managed to do a good episode. It is still strange to hear my own voice recorded, but it is still fun to do and as always I love to get involved. If your interested in hearing what I have to say (in danish) about MVC the episode can be downloaded from ANUG.

 

Tags: ,

IronPython – integrating with .NET

by DotNetNerd 25. October 2009 18:04

One of the great things about IronPython compared to other Python implementations is that is running on the .NET platform and was written in C#. This lets the developer use all the stuff he already knows from using .NET and he will have the possibility of writing components in C# that can extend or be used from IronPython. I regular Python writing extensions would be done I C which is enough to scare a big part of the developer community away. On top of that the IronPython syntax and type system is pretty close to C#, so if you are already programming in C# you will have a fairly easy time getting started with IronPython.

Doing integration of an existing language into a framework is always going to be a challenge. Some concepts in Python map fairly well to the existing .NET languages, while others require that you learn how to get about doing things from IronPython as they will require a little deeper understanding. A good deal of these challanges are covered in “The dark corners of IronPython”. The most basic thing you need to know though, is how to access classes and navigate namespaces from IronPython.

Namespaces are a concept that maps pretty well between C#/VB and IronPython, because Python has a similar concept which is called modules. In Python a module is a file which can contain any number of classes and which can be grouped into packages, which are actually just folders on the file system.

To gain access to using a class it is imported by writing an import statement - in roughly the same way as namespaces are used to group classes in C# and VB. This means that doing a import in IronPython that allows us to access a .NET class is very straight forward. (Iron)Python does have differences though. One difference is that a package contains a file named __init__.py, where you can write code that is run when the package is imported. Secondly and probably more importantly in Python the import allows you specify exactly which classes to import instead of the whole namespace/module.

from System.IO import Directory, File

This line of code will allow us to use the Directory and File class of the System.IO namespace. Writing a * instead of the filenames will mean that all classes in the namespace are imported. This is regarded as somewhat of a bad practice in the Python community though. This is basically what you need to know to start accessing .NET classes from IronPython like this:

from System.IO import File, Directory, FileInfo 
from System.Text.RegularExpressions import Regex

files = Directory.GetFiles("D:\MyFiles")
for i in range(0,files.Length):
    file = files[i]
    fileInfo = FileInfo(file)
    reg = Regex("^\d\d[\s-]+")
    res = reg.Replace(fileInfo.Name, "")
    print res

Tags: ,

JAOO Århus 2009

by DotNetNerd 8. October 2009 17:56

Actually I had not planned to go to JAOO this year, but first my good colleagues who run ANUG struck a good deal where Mads Torgersenand Oren Eini alias Ayende Rahienwould give a special talk in the evening for the usergroup. This was simply too good to pass up. After all, how often do you get the chance to see one of the Danes from the C# language team and Ayende – who is the guy behind tools like NHibernate and Rhino.Mocks.

On top of the “Geek night” as it was coined, I ended up going Wednesday for the .NET track as well. To my gain a colleague who already had a ticket could not go, so I was lucky enough to get the offer to go in his place.

It ended up being a very interesting night and day I think – with my only small complaint to Trifork, who did brilliantly, being that the .NET track was held in a building that was below par compared to “Musik huset” where the rest was held.

Key points for me was hearing Mads, Ayende twice and Udi Dahan. Madses talked about what it is like to work in the C# team, and the considerations they have to take. This was really interesting and its hard not to be a bit hit by national pride that there are actually two Danes on a team like that. 

Ayende mostly talked about his own projects with the talks focused around NH Prof and NHibernate. It is impressive to see him with a keyboard, even though I had hoped the focus of his talks would have been a bit wider. The one general issue he talked about was at the ANUG talk where he talked about concepts and features. On the upside in the day session we did get to see some of the stuff he has added to NHibernate where especially NHibernate Search looked quite interesting.

Udi Dahan gave my personal “talk of the day”, because I think he got the focus of the talk right, and managed to make it fun and interesting. The subject was pretty broad being “Scalability, Availability and Reliability”, but he made it pretty concrete without making it about a single product. The focus was on how a one way messaging architecture based around transactional queues could solve a lot of the typical issues that we run into as developers. Actually the fact that he has worked on NServiceBus did not come up until the talk was basically over and it was just named as a possible solution amongst a bunch of others.

NServiceBus will be the focus of the next ANUG meeting where my colleague Lasse Eskildsen will  be showing a bunch of good examples on how it can be used. So this was the perfect fuel to light up my interest for the subject. Besides what I have already written about there is one more topic that tickled my taste buds, which is Scala. It does not take much to get me going when it comes to programming languages, so maybe it is just me, but I think Ill have to take a look even though my focus right now is more on IronPython.

 

IronPython - high order functions as decorators for AOP

by DotNetNerd 20. September 2009 13:58

One of my favorite features from when I was playing around with F# was high order functions. A high order function is quite simply a function that takes a function as an argument and returnes a function. A basic sample just to get the point accross could be:

def Outer():
    innerText = "Hey dude! "
    def Inner(text):
        print innerText + text
    return Inner

myfunc = Outer()
myfunc("My function was called successfully")

This technique can be quite useful when composing functions, but also to wrap code and handle cross cutting concerns (e.g. like logging) through Aspect Oriented Programming. IronPython takes this concept a bit farther through what is called decorators. A decorator is to some extent similar to an attribute, and can be used to do AOP. Using decorators is as simple as defining a high order function and decorating the method that should be wrapped with @myHighOrderFunction like this:

def logging(function):
    def inner():
        print "Do pre call logging"
        function()
        print "Do post call logging"       
    return inner

@logging
def myfunc():
    print "Could do what interesting stuff you like"   
   
myfunc()

As you can see from the code it makes for a very straight foreward and elegant way og doing AOP.

UPDATE: I stumbled across this video with DevHawk where he actually shows a similar example during his talks here in DK.

Tags: ,

Community events and interesting stuff I have stumbled upon

by DotNetNerd 17. September 2009 18:56

Community events 

Over the last couple of months I have spent some time participating at usergroup events and listening to podcasts - to a larger extent than usual. Actually just today I was at "Dev Days - architecture that works", which was the first whole day ANUG event. The turnout was great and the speakers did a good job, so I think the foundation for more similar events was layed. Events like this and the passion that people display for their work is really what makes it so much fun to be a developer.

A few weekends ago I hosted my first codecamp which was about ASP.NET MVC, which will be followed up by a podcast this weekend - which will later be available at anug.dk. It's been a lot of fun and really giving to see how others approach things, and to be able to discuss issues with others that are of a technical nature, and therefore out of scope for everyday discussions with customers and projectmanagers.

Interesting stuff

Well, this post was actually meant to be build around a couple of links I wanted to give some attention, so here it goes.

I am hoping that I'll soon have more time to get back on track with blogging about IronPython - which has been parked for a couple of months because I have been busy moving and doing other stuff. A small but very cool link I found the other day actually gives you a chance to get started with IronPython withput having to install a bunch of stuff. Just go to TryIronPython.org and try it out - with my previous posts as a guide of course :-)

In another category a colleague of mine recommended a tool called Jing, which makes it possible to do short screencasts and either download them or upload them to a server and get a link that you can then pass around. Its actually just what I need in most cases when  need to show how a customer how to perform a task and it is hard to explain in words.

In the utilities category I was also recommended a tool that takes news pages that don't have rss feeds and actually exposes them as an rss feed anyway. The tool which is called feedity is not 100% all the time, but it actually does a pretty good job.

Last but not least I have a short list of podcasts that I listen to, and that I will highly recommend. They all publish casts pretty frequently, and all do a good job conveying discussions about what is happening in .NET

ANUGCast | Hanselminutes | stackoverflow | .Net Rocks! | Software engineering radio

IronPython – multiple inheritance and monkey patching

by DotNetNerd 16. July 2009 18:16

Multiple inheritance 

Besides the basic OOP stuff that I covered in my last post there are some things that you can do in IronPython which is not possible in languages like C# and java.

One nice thing that I have heard people moan about not having in other languages is multiple inheritance. Working with it is very straight forward in Python as the following sample illustrates:

class MyFirstClass:   
    def MethodOne(self, arg):
        print "1 " + arg

class MySecondClass:   
    def MethodOne(self, arg):
        print "1 Overwritten " + arg         
    def MethodTwo(self, arg):
        print "2 " + arg

class MyThirdClass(MySecondClass, MyFirstClass):
    def MethodThree(self, arg):
        print "3 " + arg

class MyFourthClass(MyFirstClass, MySecondClass):
    def MethodFour(self, arg):
        print "4 " + arg

Multiple inheritance is obtained simply by listing the classes that are to be inherited, where the order dictates the precedence of the members. This means that if the classes inherited have methods with the same signature, the first class takes precedence.

The following code can be used to test the above classes, and it also illustrates that a variable name can be reused for different types, which is a very basic feature of dynamic languages. Basic as it may be it is also one of the things that can make code really messy!

t = MyThirdClass()
t.MethodOne("MethodOne")
t.MethodTwo("MethodTwo")
t.MethodThree("MethodThree")

t = MyFourthClass()
t.MethodOne("MethodOne")
t.MethodFour("MethodThree")

Monkey patching

I wrote in my last post that it is possible to modify objects and add methods to the instance itself. Besides that it is also possible to add methods to the class in the same way. Adding or overriding methods in this way is sometimes referred to as monkey patching. As with multiple inheritance it can get really messy, but used wisely it can also make code really simple and elegang. An obvious place to use this is for mocking when writing unittests. A simple way to illustrate the technique is to first create a class and two methods:

class MyFirstClass:   
    def MethodOne(self, arg):
        print "1 " + arg
def MethodTwo():
    return "Monkey patched to instance 2"
def MethodThree(self):
    return "Monkey patched to class 3"

Now the methods can be monkey patched onto the instance and class as the following code illustrates.

t = MyFirstClass()
t.MethodTwo = MethodTwo
MyFirstClass.MethodThree = MethodThree

t.MethodOne("MethodOne")
print t.MethodTwo()
print t.MethodThree()

As the observant reader will notice it is required that MethodThree which is added to the class takes the self argument, where MethodTwo which is added to the instance does not.

monkey-thinking

Tags: ,

IronPython – OOP basics

by DotNetNerd 1. July 2009 14:12

A while ago I heard a podcast where it was discussed that some believe that languages like C#/java etc are actually not object oriented but that they are really oriented. This provoked my thinking quite a bit, since OOP was the corner stone during my education, and we wrote all code in Java.

As the discussion went on I ended up seeing their point – even though I (of course) would never admit that C# is not object oriented :) The key point is that everything in C# is based around classes because the language is statically typed around classes. In a language like IronPython it is actually possible to manipulate each object, add methods, fields etc.

Manipulating objects in this way is also known as monkey patching, and it is something I will look into in a later blogpost. Today I will start off with a basic example of how to write a class in IronPython.

The following piece of code shows a basic class with a private field, constructor, property and a public method:

from System import Console

class Customer(object):   
    "This class contains info about a customer"
    #Private field
    _saysText = " says: "     
    #Constructor
    def __init__(self, name = "Christian"):
        self._name = name  
    #Property
    def _getName(self):
        print "From within property getter"
        return self._name
    def _setName(self, value):
        print "From within property setter " + value
        self._name = value
    def _delName(self):
        print "From within property delete"
    Name = property(_getName, _setName, _delName) 
    #Indexer
    def __getitem__(self, index):
        return self.Name[index]
    #Private method   
    def _Write(self, text):
        print self.Name + self._saysText + text
    #Public method
    def Say(self, text):
        self._Write(text)

There are a few things that are worth noticing here. First of all you see that import statements explicitly state which classes are imported. A * can be used to import all classes, but this is seen as bad practice in IronPython.

Private is not a keyword in IronPython, but when a member is prefixed with an underscore (_) it is private by convention. The constructor and indexer is also named in a special way, which is what is know as magic methods. Magic methods are used instead of implementing interfaces like IComparable and for constructors, indexers and the like. Magic methods are easy to spot as they are pre- and postfixes with a double underscore. The constructor is defined with a default value for the name parameter, in the same way as you can use default in params in VB and in C# from vNext.

All methods start by taking a parameter called self. As you can probably guess, this is so it can access members located on itself – so it is used like “this” in C#, but here it is required to use it when accessing members from the object itself.

The biggest thing to notice is the way the property is constructed. Properties are quite special in IronPython compared to C#. Because the language is dynamic properties do not have to be declared up front, and this means that properties are only created when you want to do something when the property is actually called. Because this is the case there is also a delete part, which is called when the property is removed from the object.

Note that the class inherits object – this is required to use properties! This is no big issue though, because IronPython supports multiple inheritance.

When we have this in place we can use the class like you see here:

print Customer.__doc__
help(Customer)

obj = Customer(name = "Jens")
obj.Say("I'm the king of the world!")
obj.Name = "Hans"
obj.Say("I'm the king of the world!")
print obj[0] + obj[1] + obj[2]
del obj.Name
Console.ReadLine()

Functions and statements do not have to be contained within a class, so this can be written directly beneath the code above where we declared the class.

The first two likes show how you can access information about the class. The first line writes out the string that I put directly under the constructor – which is how documentation can be added and introspected directly in IronPython. The second like prints an overview of which members exist on the class, which is something you will use a lot to examine new classes as you work with them.

The rest should be pretty straight forward. A few things to note are that named parameters are used in the constructor, and that you could actually set and print any property on the object – name is only used here to illustrate that the code in the get/set/delete functions is run when the property is used.

 

Tags: ,

IIS and Server.MapPath

by DotNetNerd 24. June 2009 13:28

Today I experienced an issue with Server.MapPath which returned a path under inetpub/wwwroot, instead of returning the path relative to where my app was published. After a while I resolved to uncle google and found out that IIS apparently returns the path relative to the "Default Web Site" instead of relative to the actual site when the path is parallel to the sites physical path. I was kind of puzzled that I hadn't come accross this before, because it seems like something that would be a recurring issue. By noteing it here I hope to have it as a reminder for myself as well as it being a help to others, who might avoid pulling out a few hairs. 

Lately I have had a few requests to start writing in english, so as of today my posts will be written in english. I am hoping this will make my blog more usefull, and that it might result in more comments :-)

Tags:

IronPython – kom godt igang med dynamiske sprog til .NET

by DotNetNerd 15. June 2009 10:30

Jeg besluttede mig for nylig for at kigge nærmere på IronPython, da det virker til at være et interessant sprog, som jeg kan lære noget af. Jeg anskaffede mig derfor bogen IronPython in Action, som jeg har et godt indtryk af indtil videre.

Hvorfor IronPython?

Personligt opstod min interesse for IronPython igennem at jeg havde set en del videoer og læst blogposts om DLR, som Microsoft har bygget for at .NET platformen kan understøtte dynamiske sprog. Et hvert paradigme har naturligvis sine forcer, så en helt oplagt pointe er at man kan vinde noget ved at lære et sprog der hovedsageligt har fokus inden for hvert paradigme.

Der er mere konkret to emner hvor jeg synes dynamiske sprog virker interessante, og det er i forhold til testframeworks og som scriptsprog der kan embeddes og bruges som DSL. Begge dele bliver dækket i IronPython in Action – om end jeg ikke er nået helt så langt endnu.

Noget der meget vel kan vise sig at være en stor bonus er desuden at Python sproget findes i en række forskellige implementationer (f.eks. CPython, PyPy, Jython og tinypy), og kan derved bruges på flere forskellige platforme, samtidig med at eksisterende frameworks vil kunne anvendes fra .NET applikationer.

Derudover blev jeg gjort opmærksom på af Søren Skovsbøll at Boo syntaksmæssigt ligner Pyton en hel del, og det kan derfor være et godt trinbræt til også at prøve det af.

Installation

For at komme igang skal man umiddelbart bruge to links – henholdsvis til selve IronPython installationen og til at få understøttelse i Visual Studio med IronPythonStudio. Installationen er rimeligt selvforklarende, så man er hurtigt igang. Derudover er her en god OOP guide, hvor man kan lære syntaksen og basal objekt orienteret programmering I IronPython.

python

Tags: ,

Repository design med LINQ – querying

by DotNetNerd 23. May 2009 18:38

Linq implementationer rettet imod databaser har gjort der nemt tilgængeligt at anvende lazy loading og at opbygge querys via komposition. “With great power comes great responsibility” fristes jeg til at skrive, da den meget integrerede brug af lazy loading gør at man skal huske selv at overveje hvornår querys skal omsættes til SQL og afvikles imod databasen. Det har udviklet sig til et best practice råd i MVChvor det direkte bryder med MVC mønstret idet man flytter logik til viewet – hvilket naturligvis kan være et lige så stort problem i andre framework.

I forlængelse af diskussionen omkring hvornår querys afvikles giver Linq anledning til at overveje hvordan man vil indkapsle sine querys? Den før omtalte Repository is dead: Long live repositoryblogpost omhandler netop diskussionen om man skal have en metode pr query eller om selve filtreringen er et argument der passes til metoder som T FindOne(Expression<Func<T, bool>> expression). Kort og sagt med andre ord er argumenterne for hver indkapsling vs Open Close Principle.

Indkapsling og dermed også genbrug af querys anser jeg ihvertflad som vigtigt, men der er andre måder at gøre det på end ved at lave et repository med “en metode pr. query”. Den første tanke er tit at man kan lave en service ovenpå sine repositories som indeholder querylogikken. Det vil imidlertid betyde at en sådan service blot bliver et gennemstillingslag for simple querys – og det er kode jeg ikke kender nogen der synes er sjovt at skrive.

Filtre som extention methods en elegant måde at skrive querys der kan genanvendes og skabes via komposition ved hjælp af piping f,eks new Repository<Customer>().FindAll().WithAddress(adr).WithNumberOfChildren(2); Som altid er der imidlertid “no such thing as a free dinner”, da det ikke sikrer at querys bliver afviklet. Her er min konklusion indtil videre at jeg vil vise tilbage til den tidligere nævnte best practice, og lade det være udviklerens ansvar.

 

Tags:

Who am I?

My name is Christian Holm Diget, and I work as an independent consultant, in Denmark, where I write code, give advice on architecture and help with training. On the side I get to do a bit of speaking and help with miscellaneous community events.

Some of my primary focus areas are code quality, programming languages and using new technologies to provide value.

Microsoft Certified Professional Developer

Microsoft Most Valuable Professional

Month List

bedava tv izle