A while ago, I mentioned the next version of Cold Fusion will be able to interact with .NET code . I found out a tad bit more about this and thought it was interesting enough to post. Apparently, this interop will be care of a tool that's been around for around 4 or so years, if memory serves me. I want to say this was the first tool to come on the scene and provide true Java-.NET interop: JNBridge , which I mentioned last week . As I said before, I've never used JNBridge, but it's always the first thing that comes to mind when Java-.NET interop comes up.

Someone briefly mentioned Java Specification Request (JSR) 168  to me a little over a month ago. As most would, I asked what the heck it was about. I know what JSRs are, but I don't make a habit of knowing each one. JSR 168 turns out to be all about portal applications and, specifically, calls out a Java-specific way to implement Web Services for Remote Portlets (WSRP) . Any time I'm asked about integrating Java and .NET, two things come to mind -- and, no, one is not replace the Java with .NET... although, that is a good idea  Those things are JNBridge  and Mainsoft . I don't know much about these tools besides their existence and high-level goals. After talking to Simon Guest a month and a half ago about user experience , he mentioned how JNBridge works. I'm going to liken it to how Visual Studio allows us to easily consume web services. JNBridge creates a proxy class on the target platform that hooks into their system, which wraps the original code, be it .NET or Java, if I understood it correctly. I'm not sure how MainSoft does the job, but I wouldn't be surprised if it's a somewhat similar method.

Of course, anyone who paid attention to the fourth sentence above will notice I said JSR 168 is about web services, so you might ask why one would need to integrate Java and .NET at a component level. I'm going to chalk this one up to a mild case of stupidity. I say mild because there is some logic here, but not enough. Being the brilliant person that he is, an "architect" at a client's site determined that web services were too slow to accomplish what they needed. At first, I started to accept that. Then, I thought about how web services can be streamlined and asked what numbers they had to back up that claim. Apparently, there aren't and never have been any benchmark tests. People: If you're going to claim something is too slow, at least have some numbers to prove it. Later, I found out JNBridge was mentioned to this person before, but was shrugged off. I don't know if it's the presence of Microsoft that made him change his tone, but he was very accepting of the idea. To me, this guy is one of those zealots we run into occasionally. They always have something hateful to say about the competition, but rarely add to the conversation. In this case, he was (and still is) trying to push Microsoft solutions out of the conversation. I find that funny because... well, let me just say Microsoft has brought a lot of value to the client in the past year. We're not alone, by any means -- we work with some really good... and, with any project, some not-so-good people. I guess one of the key differentiators is our extensive training mantra along with our connections and resources back in Redmond and abroad.

Lately, I seem to be doing more and more work in the console. I started creating batch files to automate some manual tasks when I was an assistant network administrator over a group of Windows 3.11 machines. Since then, I've returned to the console off and on, but never really enough to be too concerned with how it looked or felt. Then comes PowerShell. The first time I opened PowerShell, I was in awe -- not because of what I could do, but how it looked. I liked the larger, more colorful screen. I also fell in love with quick edit mode, which allows you to left click to select and right click to copy/paste. This is huge; especially when you're writing SQL. Since I came across these things, I've wanted all of my console apps to look and feel the same way. As if that wasn't enough, I get to these apps by using Win+R, cmd or powershell. If you haven't tried that, PowerShell opens in a traditional black/gray window. Obviously, you can just click an icon, but that slows me down. If you don't know me, I'm fairly big on productivity... or, at least doing things faster

After automating more and more tasks -- namely, deploying software to a clustered environment -- I eventually got sick of looking at the black/gray and wanted my blue/white. Low and behold, the registry comes to the rescue. Console window settings are located at HKCU\Console. These are the default settings and overrides are in subdirectories (actually, sub-keys) for different times you've modified the properties of a console window. If you don't know about these properties, open a console application, click the system menu icon at the top-left of the window, and select Properties. Feel free to change it to your heart's content. I'd suggest modifying one to look exactly how you want and then save it. This will get saved to the registry, where you can then replace your defaults. To do that, browse to the customized key, right-click on the key, and select Export. Just save this to the desktop for simplicity. Next, open the .reg file with a text editor -- my favorite is Notepad2  -- and change the path to [HKEY_CURRENT_USER\Console], leaving off the sub-key name you exported it from. After this, save and close the file and simply double-click it to import them to the new location. If you're concerned about what this might do, simply export the existing console settings so you can overwrite anything you decide to undo. Here are my new defaults: ConsoleStyle.reg.

    NOTE: Open all .reg files in a text editor before executing, as they may be hazardous to your system!

It's all pretty simple and, of course, nothing new. My only hope is that we get a better overall experience for console apps. I'm thinking of a tabbed environment with real intellisense, not just tab completion. I could probably come up with a dozen more features I'd like to see, but essentially, it's all about making the console a more attractive, approachable system. Currently, newbies open it and say, "What now?"

Have you ever created or modified a master page in SharePoint? Unfortunately, I can say that I have. It's a very painful process. I consider myself fairly decent at creating web user interfaces, too. I've created a number of DotNetNuke (DNN) skins and wouldn't blink twice at doing another, but SharePoint is a much different topic. I want to like SharePoint so much, but it's just not there, yet. When I compare SharePoint and DNN, I see how much more capability and professionalism lies in the SharePoint platform; but the developer experience DNN provides can't be avoided.

Perhaps the most apparent of these shortcomings in SharePoint is the fact that web parts must be created in .NET code, without HTML. There are a few ways around this and I've been wanting to write a post on them for a few months. Maybe I'll finally get to that this week or next. The other major deficit I have a problem with, if you couldn't guess, is the effort that goes into customizing the user interface. DNN comes with a number of well-defined CSS styles that are pretty much standard. SharePoint, on the other hand, makes it hard to discern what styles are and aren't required. Maybe they all are. As if that weren't enough, SharePoint comes with the typical table-based layout Microsoft and so many other old school web designers hackers have become known for. When trying to create a "clean" layout, this becomes very hard because the Microsoft and ASP.NET controls pollute the waters so much.

I'm hoping things get easier with time, but I'm not holding my breath. Well, not for this release, anyway. I will definitely be pushing for changes in these two areas in the future. I know I'm not the only one, so hopefully there will be strength in numbers. For now, I'm thinking about looking into the CSS control adapters . Of course, I'll still have to look at the SharePoint custom controls, which I probably won't bother creating adapters for. This is the problem we always run into. We have a problem we want to fix, but don't have the time to dedicate to see it thru to a well-deserved solution everyone could benefit from.