This is a rather interesting paper and I suspect is one of two things, some of the technology in Yukon (and I suspect SP's) or some of the technology in X#. I have not read the paper all the way through yet (at first glance it looks like a summary of concpets rather than a top down explanation) but it looks very interesting.
In under two hours time I have to give a technology demo to my boss and my boss's boss (as well some 10 other people). I really don't like talking in front of people (although I have done so on a lot of occasions) I tend to start doing all the things you should never do as the nerves takes over, mumble, avoid eye contact etc. I also dread the fact that no matter how many times you go over what you are talking about, something, somwhere will go wrong (Murphys Law). To be honest I would rather stick hot needles in my eyes than do this but....the show must go on.
So, I am working with some ServicedComponents so that I can use COM+ transactions. For some reason, every time my method returns, all my fields are null. It doesn't make sense to me, so I step through the program to see what is going on. The set methods are called sure enough and the properties are indeed being set properly. So, I do a google search and find in a newsgroup posting from MS developer support that this is the "Expected behavior" for any ServicedComponent which has a method marked as AutoComplete. As soon as the method returns, the object will be destroyed. So, if you have any fields, they will be reset. Now, I have two questions: who is the moron on the .NET team that thought that was a good idea? Has he been fired yet?
Why the hell would I want to use objects that randomly lose their state?
ServicedComponents are not something I have used so I can't say for sure whats going on but reading this it makes no sense to me either. Why return a object if its going to be destroyed, it means that the object is unsable. I get the feeling that what may required is to overide (if you can) the finalize method of the object so that you can make use of the object before the GC cleans it up. I do wonder why this behaviour as been appiled, prehaps the object can't be left in memory long and the GC needs to be forced. What ever the reason its clearly not been explained.
Lately we have been swamped with Bill Gate's new .NET vision. Once again even respectable people are crying out that C++ and assembler programmers will become extinct dinosaurs. My reaction to that is: "It's not fair!" Why are they always picking on assembler programmers? We don't do a lot of harm! Just because we like to have total freedom and like to be close to our hardware doesn't make us bad people. Go pick on someone else (like LISP programmers. I don't like them). Frankly, I was getting a little tired of this whole discussion, so I decided to do something about it - by bringing x86 assembler programming into the .NET age. Well, at least to allow ASP.NET pages to be written in 80386 assembler.
A worthwhile effort if ever there was one!
LOL, I can see this taking over C# as the language of choice ;-)
Cheers Brad, these are great articles. Personally I think all .NET programmers should have at least some understanding of the the way GC works, all too often I see programmers taking it for granted...not a good idea.
Last Wednesday at we had our caching taskforce BillG review. I came into work at my normal time that morning, about , and did the usual email/spec. update/bug review/forum work. At I decided that although I'm not presenting, it probably wouldn't be a bad idea to print out copies of my caching related specs. I didn't think I'd need them, but you never know. At I headed out to the meeting.
This is a great story, a couple of bloggers have asked why Bill is not using a Tablet? Nothing wrong with pen and paper !!
Macromedia, Inc. (Nasdaq: MACR) today announced its fourth quarter and fiscal year 2003 financial results. Net revenues for the three months ended March 31, 2003 were $83.6 million, compared with net revenues of $76.3 million reported for the comparable period a year ago. Net income for the three months ended March 31, 2003 was $6.9 million, or $0.11 per diluted share, compared to a net loss of $83.4 million, or $1.42 per share, for the comparable quarter a year ago....
This is great news, I am glad Macromedia are back in the money !!
Jobs at Macromedia: Just a reminder that the company is always looking for good people. Most of the positions are in the SF Bay Area and outside of Boston, but there are occasional spots in the wider world too. If...
Any remote jobs going John (will Travel), give us a call if there are :)
"Borland's president and CEO, Dale Fuller, describes his company as the Switzerland of software development. He is molding the company's products to interoperate with a broad variety of platforms and to bridge the gap between Java and .Net." [ZDNET Webcast]
CEOs generally aren't very technical people, but this is still interesting stuff if you are wondering about Borland's plans for the future.
Its funny but Macromedia was once described (pre Alliare interestingly) as the "Switzerland" of software. Borland are really getting into serving both Java and .NET camps and proving that it can be done.
In this corner, in the purple trunks... Sean Corfield and Jesse Ezell square off on MX vs .NET. I'm not sure there's a debate here myself... finding the best tool for the job usually depends on the particular job in mind. Anyway, they have a couple of entries going back and forth over a few days... lots of text, could be a 15-rounder... I'll be waiting for the 30-second highlights on Sports Center, myself... ;-)
I have been following (and on occasion commenting) on this debate. I have found the debate has gotten off the subject a little bit but Jesse has posted a summary of his thoughts (and Sean is yet to comment).
To be honest I don't think that MX and .NET should be compared or contrasted but rather the greater sum of the parts should be looked at to see how the two can work togther. I do think that the next step for MX should be to see how it can fit into other studio enviroments so that gap between developers/designers be reduced.
My personal view is that MX could enjoy a closer relationship with .NET, true enough Dreamweaver has ASP.NET support and there is Flash Remoting for .NET but a lot more could be done for example, CFMX running on the CLR and a umanaged component for the Flash Player. Prehaps going a little further showing what can be done with .NET as they have with J2EE (a .NET version of CFMX would help this), promoting .NET as an application platfrom as much they do J2EE.
To be honest I think Macromedia could do with some .NET pros to help promote .NET in the Macromedia space and as Macromedia increase its product range for .NET those products in the .NET space.....hmmm a dream job ;-)
Following the link John Dowell left in his great comments about PPT -> SWF conversion, I eventually stumbled upon this article about using remoting in Flash MX (for those who are not aware, you can actually use remoted J2EE and .NET components from the Flash player starting with MX). Turns out that the Macromedia community's interest in design patterns is increasing as well. The difference is that it is a really new thing in the Flash community, and you generally are dealing with simpler patterns, not enterprise level patterns (still pretty cool nonetheless).
In any case, I think any .NET developer who reads the article will quickly realize why the pure .NET value proposition (ASP.NET) beats the Flash hybrid (Flash+.NET remoting) approach hands down (for example, moving all your remoted object's fields into a dictionary and using that dictionary for your get and set operations kind of defeats the point of using objects in the first place, doesn't it?).
Jesse makes some good points here. A few things stand out though.
This is an age old problem and it one that faces a designer/developer team where the technology crosses over. Its a problem that Macromedia Generator faced and to some degree never overcame. The solution may be to level the playing field, find some way of getting designers and developers using the same language. SSAS for .NET, why not.
Multiple IDEs Required In addition to needing to deal with multiple languages, you now have a project that is split across two entirely different IDEs. One of which has no Source Control support and doesn't exactly support team development. This, again, limits the ability of teams to communicate because of the same issues. Even if you're backend team did understand ActionScript enough to take a look at some source code, you can't just tell them take a look at "AccountDetails.aspx lines 20-50" or even send them the source file that is causing the problem, because if you send the FLA they can't read it unless they have Flash (and know how to use it... flash files are timeline based, not file based, so a VS.NET dev could have a boatload of fun trying to track down the line of code that the dev was referring him do), if you send the SWF file, it is like sending a DLL, it doesn't really do any good unless you really enjoy decompiling things.
If Macromedia could find a way to integrate Flash support into the VS.NET IDE, this would be very cool and eliminate a lot of issues.
I don't think this would work, Flash authoring would not fit well into the VS.NET IDE. How do you overcome this problem, well the above may help. You could also possibly allow for AS files to be external files (like JS for example) in this way you can have the UI and the code that sits behind it (which address's the point below).
ActionScript UI Layer Creating your entire UI layer in ActionScript is like going back to ASP and COM+. Yah, you get to compile your business logic. Great, but you still have spagetti code all over the place because UI layer is a mess. Some support for something like ASP.NET's code behind would be great (put your logic in a C# dll on the server). I admit, this would probably be fairly difficult for the Flash team to accomplish, but it could at least provide a door into the .NET world and would be a very cool utility.