Slashdot Mirror

There is a good write up about how one person deals with this here:
How to run as non admin

There was also a discussion about this on Broadband Reports
Runing as admin

My favorite tool for the integration is JuggerNET, which transparently starts up a JVM in the CLR process and the developer simply codes against generated .NET classes. I am affiliated with Codemesh, so I'm somewhat biased (take a look at Stu Halloway's great website for alternatives) but working with both platforms for a living, I just can't get excited about controversial this or that is dying statements. Both platforms have their strong and their weak points.

I love the platform portability of Java, but I think Java is too closed in terns of language integration. Doing JNI by hand is an abomination, and most people at Sun admit it.

I love the language portability of .NET (it's not perfect, but then, neither is Java's platform portability) but I hate the exception model.

So, there you have it. Neither will kill each other, they will just coexist uncomfortably until they both get replaced with something new.

The replies to this message apparently are very skewed towards those that receive little or no training, or of training with little quality. I'd like to add a counter balance to that.

My background: I've been a trainer for two years for a small training & consulting company out of New York (though I've since moved on). I've trained (and consulted) globally, with my courses ranging from beginner to advanced Java, C++, Web Services, XML/XSLT, J2EE, EJB, and most recently the Microsoft 2-day VS.NET seminars. I've taught principal engineers and developers of products you may have heard of, as well as various other companies.

Is training worth it? It depends. The main benefits of training vs. books are:
a) you can't ask a book a question
b) books can't help you when their examples don't compile
c) you'd like to get an answer to that gnatty problem you've been experiencing in that DLL you've been screwing with for 3 days (i.e. free consulting advice)
d) some authors really can't write
e) some technologies are so new or specialized there isn't much in the way of quality books out there (i.e. advanced oracle performance tuning, advanced J2EE architecture, writing for an EAI framework like TIBCO, etc.)

Training is a way of imparting knowledge that the books have IN CONTEXT of the real world AND providing the extra knowledge that the books don't have.

Most training sucks, of course, because
a) it's not relevant to your day-to-day job
or
b) the buyer doesn't know what constitutes good training.

This really harkens back to the scourge of the land of IT: a lack of good managers. It's up to managers to know what training is needed & whether the vendor is of sufficient quality. It's also up to the managers to involve the team with this decision -- I fully agree with the premise of this article that those being trained should influence the training -- if you're not seen as being competent enough to know what you need, there's a real reality-deficiency occurring.

Given the above, what makes a good instructor for technical courses? IMHO, in order:
a1) advanced technical knowledge & expertise
a2) good teaching skills
b) patience
c) energy (you have to carry the crowd through the tough parts)
d) humility (you can sometimes be wrong)

They're all needed, though at bare minimum A1 & A2... if you have teaching skills but don't know much, you're not accomplishing anything except entertaining/babysitting a crowd for a few days. In an advanced crowd this will generate a lot of anger. Conversely, if you know a lot but have the communication skills of a potato chip, you'll still get a lot of angry people wanting to give you the boot.

Having said that, a good course with a good instructor can be a very rewarding experience, probably a major highlight of your career growth -- assuming you get the right course for the right reasons with a good instructor.

In perspective, a 5 day course can run between $1-3k a person, depending on the depth, level, and reputation of the instructor. That's not cheap. It's probably only worth it to go with the "world class" instructors, whether well known (like the folks at DevelopMentor, or Hotsos), or relatively unknown but promising (like my old company).

As for what industries regularily offer training -- generally in my experience, financial and insurance companies. There's always ongoing training there for new technologies, and most new IT hires get 4-12 weeks of training in business and technology.

1. Newsgroups: Most microsoft technologies have a newsgroup in the microsoft.public.* hierarchy that are read not only by Microsoft employees but by dozens of regular developers who just want to help others who are having problems. I personally monitor microsoft.public.xml and microsoft.public.dotnet.xml where I answer a lot of questions and pass many of those I can't answer to the actual devs who work on the applications and APIs in question.
   
   
2. Online Communities: There are a number of strong online communities where Windows developers congregate to share information, tips and tricks. These range from Microsoft sponsored sites like GotDotNet, ASP.NET, and Windows Forms.NET that are run by MSFT employees who participate actively in these communities to independent sites like 4 Guys from Rolla, Code Project, Dev Hood, DevelopMentor and CodeGuru
   
   
3. Microsoft Websites: Few places beat MSDN as a source of information about Microsoft technologies. By the way, if you are into XML check out my Extreme XML column
   
   
4. Mailing Lists: There are number of mailing lists hosted by various parties about Microsoft technologies. The ones I've seen with the most vibrance have been the DevelopMentor mailing lists and the ASP Friends lists

Mr. Box was not saything that HTTP is not good as a Hyper Text Transfer protocol, he was stating that it's being manipulated to perform RPC, which is true. The theme of the artical was on how HTTP is bad for RPC, which you seem to also agree with.

Simply because this guy now works at Microsoft does not mean he has an agenda for evil. As a matter of fact before working for Microsoft Mr. Box started a little company called DevelopMentor, He's also written a few books One of which is concedered "The" book on COM, Essential COM, ask any COM developer worth their salt if they own a copy, they do.

I've known of Mr. Box for years now and trully recpect him as a technical writter and developer and I honestly don't think that he would shill for Microsoft.

-Jon

GC and deterministic finalization are orthogonal concepts - they can co-exist. A determinstic "destructor" if you will can call a different function than the finalize method - perhaps Destroy() or something. Deterministic finalization need not be concerned with what other objects may be pointing to that object - it is only a contract to call a certain method when you either go out of scope or when an expception is thrown. Here is a C# language proposal from Microsoft for deterministic finalization. Here is an example:

using (File f = new File("c:\tmp")) {
byte[] b = f.Read();
}

Personally I think the parens and the block following the using clause are useless syntax that only add more unnecessary verbosity. I think the following would suffice:

using File f = new File("c:\tmp");


and the destructor would be called when it went out of scope (just as in C++). Calling Dispose() directly all over the place in try/finally blocks is not only error-prone in my opinion but makes the code less readable and significantly larger.

One of the reasons thati've balked at micropayments for individual pages is because of revisions. You'll go to the page, it'll get downloaded to your cache and there it'll remain until you 'redownload' it. Browsers will have to be changed to accomodate the notion that 'if i go to a page i may not want to redownload it' - giving you a revision index that will become unmanageable. Luckily we'll have a new storage medium explosion by then, so the fact that any web-connected computer will need a base of 30gb space won't be so big of a deal.

Then you'll get the chumps that will update something small - like the footer date, to trick you browser into announcing that a new version of the page is available. New browser revision will then start to trickle out that will tell you how many bytes have been changed from the old revision to the new one (if the protocols allow for that).

Next you'll see the emergence of Freenets, where content is not charged for. This will lead to a dichotomy that will cause a split in the net between 'corporate nets' and 'freenets'. 50 years later the prejudice will sift down to the hardware level and the corps will try to dump 'freeloaders' though legislation. They'll use the backing of eliminating 'pirate content' sites, which will post the most up-to-date revisions of any pay-per-view page. A new DCMA provision will come to vote

by this point though wireless hardware will ahve reache dthe same level as 486s and any kid will be able to tinker together mininets that they'll broadcast out of their backpacks as they walk down the halls at school. Teacher's won't catch on for a while, and only the most progressive schools will ban carrying backpacks to class; but it won't matter since those (probalby private) schools will mostly have rich kids anyway, that will buy smaller tech and hide it in a hollowed out book.

...and hopefully SOAP or it's equivalent will allow for the creation of elegent network-mapping tools that will generate data visualizations as you walk down the street and brush by local freenets, getting a 'feel' for the data-fare before you decide to jump in.

-shpoffo

I picked up one of these after reading about it on the aforementioned Practically Networked site. (You can see a picture of it here). It's serving as my DHCP server now, freeing me from always running the PC that used to do it.

The device has functioned very well for me and has lots of capabilities. It has a somewhat lame web interface, but anyone who has ever used Telnet will find it easy to configure it to do the more advanced stuff. Yes it does do NAT, and has built-in support for ddns.org. All in all well worth the ~$100 at Best Buy (which, btw, was HALF the price CompUSA wanted).

Knowing Microsoft, bugs will remain to exist in their software, ie Outlook, that nice newly discovered bug in Office XP, and so on. Presumably the same will be true of approved third party software. SOAP would appear to involve passing XML through port 80 ie as an HTTP request (not so bizarre in a sense)... which when you come to think about it means that a sysadmin (or any firewall software user) can no longer rely on blocking ports to secure a computer.

Meaning that firewall software is going to have to make more of a point of scanning for content, just, but it's strange how Microsoft manage to add 'security' by constraint whilst simultaneously messing up in the other direction. It's not going to be enough to lay down the law to software vendors about 'the highest security levels' without going into 'why we use standards and don't go off doing whatever the hell we feel like just to confuse sysadmins and break firewalls'. (This might be why Schneier seems so dubious about the measure...) Having said that, congratulations to all 170 members of the Center for Internet Security for trying - at least it gives them legitimate grounds to gripe when Microsoft open new and innovative ways to destroy PCs and deliver viruses via HTTP and email...

The new universal runtime takes (obviously) a very substantial amount of ideas from java and expands on them

What exactly does it expand on?

- You can pretty much write in the language of your choice on top of it.

No, actually you can write in one of the supported langauges on top of it, all of the useful ones of which have corresponding projects that target the JVM. Nothing I've seen about the CLI or the CLR suggests to me that it's got anything over Java. IL is just JVM bytecode warmed over. There's nothing about JVM bytecode that inherently ties it to the Java Language - just judge from the ports of Perl, Python, Scheme, etc. As long as a language can understand the Java object model, it can compile/reconstruct JVM bytecode, thus enabling it both inherit from Java libraries and allow inheritance from its own libraries. There's no particular reason, for example, why C# can't be compiled to JVM bytecode, since the object models are easily mappable between the two.

- C# introduces some ideas that are, imho, an improvement over java such as boxing, where for example, a native type such as an integer is transparently converted to the object type without the need for function calls.

Wow, now there's a feature, because those wrapper types are so painful to call -

Never mind that explicit object encapsulation of primitives provides some uses of its own - protecting against accidental casting comes to mind.

- A huge cool aspect is that the runtime seemlessly allows interaction between none runtime and raw code. Thus, you can implement parts of your c++ code in the same module to run in the runtime environment and other parts to be 'raw'-- but they can still call each other without the need of special interface layers (aka JNI). Thus your handy dandy super duper collection of anyting in the world could run on top the runtime, thus being garbage collected, and the rest of your code could run 'raw' outside of it.

Yes, but all the data types you want to transfer between your 'raw' elements and your 'safe' code have to be part of the managed extensions Microsoft has introduced, so you're still going to end up rewriting large sections of code. Besides that, all of the overhead of JNI is still there, it's just abstracted by the runtime.

- COM developers are going to like this runtime a lot. It introduces 'revolutionary' (sarcasam) ideas such as searching in the current directory for a COM object and not requiring really gross GUIDs to load interfaces and libraries.

So it's finally catching up to Java in this regard? Whoopee. I will admit that the abstraction layer that allows old COM objects to plug in to .NET seamlessly are nice, but there are similar projects to make it work for Java on Win32 platforms, too.

The obvious attraction of some of these features is enough for any developer to say hmmmmmmmmmmm

No, actually they're enough to make any Java developer say "yawnnnnnn...."

Nobody ever said that we should be copying .NET from the ground up. What we should be doing is making it possible to talk to .NET's Web Services, which should be possible, since SOAP 1.1, WSDL, and UDDI are open protocols, and are probably going to make up the W3C XML-RPC spec when it's finished. The rest of it's fluff - I don't think anybody's going to worry about making Web Forms work on Linux, for example. C# and the CLR have nothing to do with Web Services - they're just an attempt to steal Java's thunder on WORA. The Java community is already working on Web Services APIs for Java - JAX-RPC and JAXM. That's where Open Source developers should be concentrating, too.

The most important thing besides getting tools that speak the wire protocols is creating something to compete with Microsoft for authentication services. This is where Microsoft expects to control the whole ball of wax. If they are the only authenticators, they can charge for every transaction. If Ximian is smart, they'll release an authentication framework as soon as they can, hopefully not long after Hailstorm is in the water (since before is likely a hopeless cause at this point).

In Visual Studio.NET (beta 2 code)

(a) Go to the "Help" menu, select "Edit Filters"

(b) In "List of Available Attributes and their Values" expand "Target Operating System (TargetOS)

...and you will get....

UPDATE (5 p.m.): HERE IS THE LIST OF OS's THAT .NET WILL SUPPORT:

The "Target Operating System (TargetOS)" list is:

Linux (kbLinux)

UNIX (kbUNIX)

Windows (Windows)

Macintosh (kbMAC)

Windows CE (WinCE)

1. C# is primarily a Java based language that fixes a couple of things Java got wrong (there is now a const keyword, there are out parameters, there is a foreach construct, there are enums, etc) and also has some annoying holdovers from C++ (what's the deal with the virtual keyword?).
   
   For ease of development I'd rank them about equal. If the development is Windows based then C# beats the pants off of Java since it has access to certain APIs directly instead of having to go through JNI as would be done in Java.
   
   
2. Java is write once, run anywhere. This is a major advantage if you are running lots of client Java code on varying platforms. But since most Java development is server based then the fact that a program is WORA loses its charm. Secondly most Java communication between various platforms is done via RPC mechanisms (CORBA or RMI) and .NET supports an XML based RPC format called SOAP which is as cross platform as you can get since all the other platform needs is an HTTP server.
   
   

"During the presentation I was asked about whether or not there were 2 or more implementations of the CLI. At Microsoft we have implemented 2 versions of the CLI. These are known as our .NET Frameworks and .NET Compact Frameworks. Further it was asked what platforms these were running on. Currently Microsoft has these frameworks running on all the Windows platforms (Win2K through WinCE) and 1 non-Windows platform. Unfortunately I'm not able to comment any further on the non-Windows platform."

"During the presentation I was asked about whether or not there were 2 or more implementations of the CLI. At Microsoft we have implemented 2 versions of the CLI. These are known as our .NET Frameworks and .NET Compact Frameworks. Further it was asked what platforms these were running on. Currently Microsoft has these frameworks running on all the Windows platforms (Win2K through WinCE) and 1 non-Windows platform. Unfortunately I'm not able to comment any further on the non-Windows platform."

The SDK preview includes a copy of the C# compiler with Win2k Professional. (Note that the SDK does not include the Visual Studio 7 preview, but it does include "ASP+, the Common Language Runtime, documentation, samples, tools, and command line compilers.")

Microsoft also has some public newsgroups (hosted on "msnews.microsoft.com") for discussions about the .NET frameworks, C#, C++, VB, etc. And DevelopMentor is also hosting a .NET mailing list.

The August 2000 issue of MSDN Magazine is also featuring an article about C#.

I see two major technical advantages to SOAP.

1. It spec's a set of HTTP headers to make it more firewall friendly.
2. It easily supports multi-reference data/cyclic data.

DB
http://www.develop.com/soap/soapfaq.xml

I'm sorry you are not happy with SOAP. Your comments are interesting. Here's my take on what you stated.

SOAP deliberately doesn't mandate object semantics. It also doesn't prohibit it. SOAP also doesn't explicitly support session or tx IDs. I am not sure you are reading the same spec I worked on (we used a tx id as an example application for protocol extensions but by no means mandated or even spec'ed them).

As for objrefs being explicit, I'm not sure what you mean. URLs are pretty explicit in the HTTP protocol and they are in essence our objref format. As for server-side persistence, SOAP isn't trying to mandate a CORBA-esque (or COM-esque) programming model, just a wire protocol. It would be trivial to layer a POA on the back end (RogueWave/Neuveau are doing just that I believe).

As for tunnelling IIOP or DCOM over HTTP, these are PROPRIETARY solutions and I don't know if any orb vendor has implemented the OMG spec for dealing with firewalls in a shipping product.

DB
http://www.develop.com/soap/soapfaq.xml

I take issue with the following quote regarding XML and XML-RPC:
It's a bad sign that Microsoft knows more about this than the leaders of the Linux community. They've already incorporated it into a new protocol that they are calling SOAP.

Ok, I'm far from being a "leader" in the Linux community (or any other), but I've been monitoring the XML-RPC and SOAP discussions for a while now. Many of the underlying grammars were clearly written by people who like COM. The data types conveniently mirror COM VT_xxx types. They CAN, however, be implemented in other languages and platforms. (IIRC, Zope implements XML-RPC.)

Personally, I have misgivings about SOAP being used for real cross-platform distributed computing in the future. It just seems to make too many assumptions about data types. XML-RPC seems geared towards replacing CGI -- it specifies port 80 for all communication (which seems a little narrow-minded to me). These may still become de facto standards because they are "good enough" for most cases.

I predict that for the next few years we will see several new XML grammars introduced. In time, we will eventually settle on a few that work best for most people. Maybe SOAP will be one of these, maybe not. Maybe it will be a derivative of SOAP. Maybe it will be something completely different.

Right now, XML-RPC/SODL/XMOP/SOAP have momentum and the backing of Microsoft and a few authors who want to be first on the shelf with "Designing Distributed Applications with SOAP for Dummies" I'm not aware of any alternatives to SOAP right now. Maybe there is no need for one.

If you've gotten this far in my long-winded post, you may want take a look at a few sites relating to XML and distributed computing:

http://discuss.develop.com -- SOAP discussion board.
http://www.xml-rpc.com -- XML-RPC specs and discussion.

My own shameless plugs:
http://www.maiermedia.com/lab/xml/opml.t xt -- My OPML proposal for object persistence in XML. It's crude, but I think it has less platform affinity than SODL.
http://www.maiermedia.com/lab/xml/ opmlsample.txt -- A sample of objects serialized in OPML.

At this point, I've shelved OPML because I don't see any point in competing with the SOAP crowd. If you do take the time to look at it and would like to send suggestions or feedback, my email address is donkpunch@maiermedia.com. I would love to get some input from people who aren't already convinced that SOAP is the best solution. Maybe I gave up on the idea too soon.

Thanks.

Don Box is a well-known COM expert. He wrote this script that generates GUIDs in the open, without MAC information:

GUID generator

have fun.