Firefox annoyance – rare but true
I have been a Firefox fan for a couple of versions now and always but I cant
believe this really annoying great feature in the latest version (3.5) of Firefox. If I hover over any part of a page, it displays an empty tooltip.
It’s hardly a feature that gets in your way but it’s damn annoying. Even if I hover over the vertical scrollbar I can see the damn thing. Apparently there has been some history of tooltip strangeness with Firefox in the past but I haven’t really delved into it too deeply.
Anyone heard of this problem before or experiencing it with the current version?
NServiceBus has made messaging an easier choice.
I am finding it harder and harder to find scenarios where I would consider anything other than NServiceBus to build messaging systems behind the corporate firewall. Certainly punching a hole through it might open up the possibility for other technologies, but in most cases it’s to act as a bridge to what will eventually hit some NServiceBus infrastructure.
Deployment is a snap and in a project based environment where small systems are regularly custom built to order for heavy load batch processing, NServiceBus will make rolling out a highly scalable solution a very quick and reasonably simple process. Also, NServiceBus configuration is far simpler these days and to be honest, compared to some frameworks it’s downright simple to understand.
The kind of processing numbers we are achieving in current proof of concepts for new projects are impressive and the deployment story is going to let us ring out every last drop of blood from hardware otherwise considered as redundant and useless. Not a web server in sight!
One thing on MY the Network Administrators wish list is a zero deployment transactional queue (transport). Andreas created a file based ITransport implementation but unfortunately no support for transactions, however it does show just how extensible NServiceBus is.
An IronPython REPL Console in a WPF User Control
Recently I posted an IronRuby Console, purpose built as a WPF user control. The basic reasoning was to allow me drop in scripting into any given application or User Interface. In more recent times (with some help from Michael) I decided to ‘jump ships’ and move to IronPython as my choice DLR language. Given the change in direction I was obviously going to need my console window to support the language of my choosing.
The New IronPython Version
So to move forward with the WPF user control console project I decided to refactor it to support IronPython. Mark has jumped in just recently and started to contribute by adding the new “cached commands”, which offer up / down arrow repeat command behaviour such as found on a DOS console. You will also notice from the screenshot above I have imported the entire System namespace to demonstrate that it is possible (using the environment menu) to print the entire state of the default scopes current set of variables.
Now it’s true I could have done this in a way that allowed for switching between the languages, however I have delayed that decision until IronRuby reaches it’s version 1.0 official release. In the meantime you can now use the IronPython version or the IronRuby Version seperately.
I am going to follow up shortly with an example of how this little window can be become quite useful in a practical way.
Downloads
IronPython Console Window Project
IronRuby Console Window Project
No REST from reading!
I just received IronPython In Action and cant wait to tear into it, I just have to get RESTful.Net off the bedside table and I’m good to go. Not since NServiceBus fell across my path have I been this excited (not that I am comparing them). If only there was a book on NServiceBus? Udi what say thou? The world is ready for it…
Why I chose IronPython over IronRuby in the end.
Initially when I made the decision that I would benefit from learning a new language that adhered to a different paradigm (dynamically typed), I selected IronRuby over IronPython simply because I had seen it first and perhaps got caught up a little in the industry hype and good PR going on.
After having spent a less than insignificant amount of time invested in IronRuby I decided to bite the bullet and invest the effort into IronPython instead and the reasons were entirely pragmatic. Microsoft seem to be putting more effort into IronPython, has already found it’s way into other stacks, such as Oslo’s Intellipad (which I plan to leverage) and it’s significantly more mature than IronRuby.
I am constantly finding uses for IronPython in my work and the list of problems that it’s going to help solve is growing quickly. As a side note, if you are looking to use IronPython and are ready to let the experience pass you by because of lack of IDE support then check out using NetBeans (for Python) and instead using IronPython. As previously detailed by Steven and David, you can use the NetBeans Tools menu and make the selection ‘Python Platforms’, then you can configure a new default platform setting and redirect the IDE to use IronPython (see above screenshot). I haven’t used this configuration for long but for now it seems to work nicely.
