I’ll get to posting the real content (Specifically, introducing Castle Windsor into our application stack, and how that makes possible a very loosely coupled architecture).

Here’s the juicy details. We’re developing a new system from scratch, after finally realizing that what we’ve been doing for the last ten years isn’t, well – you know, keeping ut with the times. Java here, Sybase there, .Net there and some C++ and even PowerBuilder thrown in for good measure.

Instead, we’re re-architecting ourselves as a service provider, providing a service instead of several pieces of distinct software. Now, mind you, we’ve been doing this half-heartedly for years already, outsourcing core parts of our business to external “service providers” (bear with me here), but our business has always been about the Installer and the Database(tm).

What does this mean for us as a company? Well, first and foremost it means that I finally get to implement some of my many, neverending ideas. Mostly those are focused around WCF, Nhibernate and a loosely-coupled, service oriented architecture.

Now, here’s the catch. Everything I read, almost everywhere on the web, is focused on a single web application talking to a single database. Wake up, people. This isn’t, BY FAR, the way business is done in the real world. We have third parties that are vital to our business, those third parties need access in varying and distinctly different ways. We have customers that need a simple one-off setup for a few weeks, and we have customers that have longlasting, complex relationships with us as an ISV, OR as a service provider(tm).

So here’s what I intend to do. I intend to document how we use Real Technologies to accomplish Real Work. If you’re interested in seeing how that pans out, I suggest you stay with me. I’m going to try to detail as much as possible about how we approach this – and I can only assume this – very common scenario.

I’ll start tomorrow by discussing how we intend to make our Domain Model blissfully unaware of how it is being used. Factories, Interfaces and Repositories galore. Mind you, we’re only starting out, and I’m semi-hoping (is that even a word?) that I can also get some valuable feedback from you, my dearest reader, on our sure-to-be many mistakes.

See you tomorrow!

There is simply so much wrong with the current direction of Microsoft's Atlas project, I won't even begin to summarize it all here. But suffice it to say that this looks a ton like the early ASP.Net 1.0 "efforts". Way too much focused around Microsoft's own browser to actually make it useful.

When is Microsoft going to understand that STANDARDS MATTER!?!?!
read more | digg story

In my professional life, I'm only afraid of a few things. John's keyboard, which is coated with that fine patina of brown gunk. A call in the middle of the night saying the app server won't start. And the dreaded request: "Russ, see if you can speed this code up." It's usually code I've never seen. It's probably important, otherwise they wouldn't be worried about how it is performing. And speed it up to what? Still, there are some basics you can fall back on when someone asks you to optimize some code. Here goes…

Russ – we've all been there. The dreaded "can you take a look at this". Thanks for the valid points in your blog posting – what you're talking about is something every developer should keep in mind.

The post reads as follows:

Hello IronPython Community,

We have just released IronPython 1.0 Beta 6. This release focuses primarily on fixing bugs and improving compatibility with CPython. Major cleanups includes supporting __metaclass__ at the module level, using __mro__ for new-style class method resolution, and a massive cleanup to make sure all of our comparisons are identical to CPython. With this release we’ve also improved the performance of calls to arbitrary .NET assemblies by enabling our call-optimization for all assemblies and updated the tutorial for beta 6.

One change that has the potential to break people in beta 6 is that we are deprecating clr.Path and instead suggesting everyone switch over to using sys.path instead. This is more inline with how CPython searches for .pyd extension files and we believe will simplify the loading story. This also means that the current working directory will be included in the search path by default which seems to have been an issue that caused many problems.
In this release of IronPython we’ve introduced a breaking change concerning the treatment of .NET value types. We’d like to elicit your feedback on this change to determine if it needs tweaking or outright changes prior to a V1.0 release. You can read more about this specific change at http://channel9.msdn.com/wiki/default.aspx/IronPython.ValueTypes

A more complete list of changes follows at the end.

You can download the release from: Microsoft Download Center > IronPython Beta 6

We’d like to thank everyone in the community for your bug reports and suggestions that helped make this a better release: Andrzej Krzywda, Erin Renshaw, John Platt, Jonathan Jacobs, Mat Steeples, Mathew Yeates, Nathan R. Ernst, Nichlas Jacobson, Richard Hsu, Seo Sanghyeon, Stanpinte, Szymon Kobalczyk, Tragic_hip, William Reade.

Thanks and keep in touch,
The IronPython Team

More complete list of changes and bug fixes:
============================================
Fixed precision formatting bugs in string formatting
Enable ReflectOptimization for all assemblies and methods (improve .NET function call performance)
Add update and other missing functionality to module & class dictionaries
Fixed bugs in list comprehension code gen
Implemented -W (warning filters) command line parameter
Improve IronPython test suites ability to run on both IronPython & CPython
Able to run test_list from standard CPython library distribution (w/ 2 tests disabled)
Fix equality check in if statements
Cleanup semantic issues in IronPython code base
Fix tabs to align at offset of 8 rather than incrementing by 8
Add Line information to PythonSyntaxError
Fix for x in d.keys() at console not raising syntax error
Fix repr / str results on old class to match CPython
Fix > 5 arg case for calling optimized functions w/ params
Make sys.exc_traceback a writeable attribute
Add __mro__ for new-style classes and use it for method resolution
Add support for __metaclass__ defined at the module scope
Enable inheritance from both new-style classes and old-style classes
Prevent subclassing from the same type twice
Enforce inheritance restrictions for MRO.
Can now run test_slice unchanged from CPython standard library regressions
Add running test_xrange from CPython standard library regressions
Disable useless assignment to mutable value types
Console end-of-input detection cleaned up
Bugfix: sgmllib still not compiling (re module bug)
Implement popen in os module, and other functionality as well
Bugfix: File object lacks closed attribute
Add support for creating file from .NET stream w/ mode
Bugfix: File object lacks tell method
Bugfix: loading a py file crashes winforms (race in winforms.py)
Fix RemoveRange in conversion wrappers
Bugfix: IronPython lets you delete builtin functions by specifying the name
Support getting CLR type object from Python type object (clr.GetClrType)
Bugfix: Assigning or Deleting events should throw a TypeError exception
Bugfix: selfmodifyingComparison in list.sort
Bugfix: Match CPython 2.4 behavior for base64.b64decode
Fix IndexOf bugs that can result in IndexOutOfRangeExceptions in conversion wrappers
Bugfix: enable deriving from complex
Bugfix: leading space sometimes not reported as a syntax error
Bugfix: False == None ?
More FxCop cleanup
Move rarely used object dictionaries into SymbolId dictionary
Enable access to CLI assemblies & namespaces via __dict__
Bugfix: generation of RealEntryPoint in CodeDom
Bugfix: CodeDom no newline afer def of _ConstructorFieldInitFunction leading to parsing errors
Bugfix: CodeDom: Empty try blocks not handled correctly
Bugfix: CodeDom: Emitting a try with multiple except clauses aligns indentations incorrectly
Bugfix: COM import does not iterate over interfaces
Add COM interop test harness
Bugfix: Types don’t evaluate to True, instead they throw
Bugfix: reg ex differs from CPython (matching & groups)
Fix filename shown in file
Fix bug in startswith
Improve error message in XRange.AddSequence/MultiplySequence
Improve error checking on function calls
Add large number of compatibility tests for comparisons of built-in types, new-style and old-style classes
Bugfix: Fix CodeDom generation & round tripping of fields w/ init expressions
Bugfix: Fix CodeDom resolution of private methods
Improve testing of console
Bugfix: CodeDom IterationStatement parsing and generation is broken
Bugfix: CodeDom CodeConditionStatement parsing w/ non-null FalseStatements is broken
Bugfix: Fix some issues w/ empty blocks in CodeDom
Bugfix: ReflectedNamespace.DeleteAttr wasn’t working correctly & other object ID keys fixed
Fix ArrayOps issues
Enable use of instance operators defined from C++/CLI
Fix StackOverflow when calling Ops methods
Bugfix: Fix handling of unmappable Unicode characters in CodeDom
Bugfix: Invalid generation of CodePrimitiveExpressions for single chars
Bugfix: Fix MulticallGenerator issues
Improve thread safety of IronPython
Improve & fix issues in IronPython Tutorial
Bugfix: ReflectOptimizer doesn’t call Ops.ToPython
Implement sys.setrecursionlimit and set default recursion limit to unlimited
Fix CodeDom support for using a TextReader
Improve stack trace shown after keyboard interrupt
Support in-memory compilation in CodeDom
Remove clr.Path and use sys.path for assembly loading

Shame on you, Microsoft. Shame on you, but not just for not doing better. We expect you to copy Apple, just as Apple (and Linux) in its turn copies you. But we do not and should not expect to be promised the world, only to be given a warmed over copy of Mac OS X Tiger in return. Windows Vista is a disappointment. There is no way to sugarcoat that very real truth.