Monday, January 26, 2009

Pinsor Python DI/IoC framework

Well we'll see where this goes, but I finally decided to give back to open source a bit (besides being an advocate and willing trainer for those interested).

Pinsor Google Code Project

There doesn't seem to be much demand for IoC in Python (in fact anger see comments), but there wasn't in the DotNet community for a long time. I believe the trick there was making IoC containers that people wanted to use for their language (read not 4000 lines of xml that you found in Java containers so often back then).

Hopefully, my aim here is to bring auto-dependency resolution and cut down lines of code in an app, everything else that people typically blab on about with IoC/DI is staggeringly less important.

This is an area where I fundamentally disagree with the most users of IoC frameworks who tend to pound DI DI DI and TESTABILTY. Dependency Injection in of itself is a concept that's so bloody simple you can get it in 5 minutes of working with any language if you just accept it (which is by far the hardest part), and not the important part.

The most imporant thing pinsor will aim to bring is less lines of code in moderately complex projects or greater, if it doesn't accomplish that then I'll be the first to delete it and remove it permanently. My focus will therefore be on making sure automatic dependency resolution and convention based configuration are fluid and easy to use.

As I refine the api and get a pythonic configuration DSL up I'll post examples and add to the docs. Till then you may use the unit tests (which are done with a bit of Behavior Driven Development style).

Sunday, January 11, 2009

Developer Professionalism and Chad Myers

Generally speaking I like Chad Myers comments a lot, some of it he has more experience and that leaves me with less material to challenge his ideas, but sometimes he just see's the world the same way I do.

This post is exactly what I've felt for so terribly long, especially the parts about magic, hocus-pocus and charlatans. Its lonnngg past time computing in general move out of the voodoo phase. So here is my advice for aspiring professional developers, technicians and support techs:

Firstly, technology is not to be applied with the same logic as sports teams. Just because someone started liking Windows, Linux, c#, python, oracle, mysql, whatever does not mean that is the only technology in the world and one must support it till their dying day. Things are good/bad on their own merits, and most work in one situation or another, and what was once bad can become good and vice versa.

Let me state this REALLY clearly. Every time you refuse to dive into a technology because "it must be inferior" and you haven't actually tried to get some work done with it, you are hurting YOURSELF.

Secondly, things are not what they seem on initial examination. If you dont know how something works say so! If you don't like something, give it a deeper look and try to use it, talk to those that actually do use it to get work done on a day to day basis.

Thirdly, if something breaks, or acts in a way you didn't expect. Figure out why that is, with analysis and thought. Use the scientific method, only change one variable at a time, and dive deeply until you are satisfied with your findings. Even then don't trust what you've found is gospel.

Finally our job is to serve as tech experts for those that aren't tech experts. This is a delicate job at times, but honesty and building trust is mandatory. Bullcrap solutions/explanations that may fool the customer for a time have a way of sooner or later exposing the bullcrapper as a useless expert to deal with. Regardless, those that give good timely honest solutions and explanations with a touch of humility end up being the ones that everyone relies on.

That's enough soap box for now, but at the end of the day if the industry as a whole acted that way, I'm quite certain we'd have a lot less "awful legacy code", less management interference, and we'd be focusing on delivering business value to customers (and delivering it quickly) instead of geek ego.

Friday, January 2, 2009

Remoting objects (yes I know it's not 2001) without using the MSDN Way

Ok very few people use Remoting Services any more but it's good in a pinch for quick and dirty way of doing distributed applications.

Now when I went to first use Remoting I struggled to make it fully usable as the books I was using (as well as a quick Google and MSDN lookup) had me all using code like so:


// Create an instance of a channel
TcpChannel channel = new TcpChannel(8080);
ChannelServices.RegisterChannel(channel);

// Register as an available service with the name HelloWorld
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(SampleObject),
"HelloWorld",
WellKnownObjectMode.SingleCall );


The above code instantiates (calls: new SampleObject() ) an object to be able to accessed remotely..but it cannot take any arguments in the ctor !!

This ended up causing me no end of grief, because if I wanted to write a remoting test, I was pretty much stuck with whatever "new SampleObject()" initialized. Now I was forced to open up configuration changes via setters!

Eventually I scratched the whole thing when I found out Castle Windsor had a remoting facility and just used that to handle my remoting needs and it works quite well.

Looking through Castle Trunk they use RemotingServices like so:


internal static void Marshal(object instance, ComponentModel model)
{
MarshalByRefObject mbr = (MarshalByRefObject) instance;

if (!Convert.ToBoolean(model.ExtendedProperties["remoting.published"]))
{
string uri = (string) model.ExtendedProperties["remoting.uri"];

// key logic is here
RemotingServices.Marshal(mbr, uri, model.Service);

model.ExtendedProperties["remoting.published"] = true;
}
}




So with RemotingService.Marshal(object, uri ) is the key here it takes an already intialized class and makes it "remote" and available as a service to another client somewhere else. So much more flexible!