What the HELL do you mean by "decipher the insane implementation behind the \"smoke and mirrors\" ?
The idea is that you're NOT SUPPOSED to both with it. Interfaces are there to be used, not reverse engineered. If you wanted to know what the F$%#king component was doing, you should've bought the source license.
Visual Studio 6 was absolutely the WRONG IDE to use.
There is...in this months ( Sept 2003 ).Net magazine, there's an article about what they call "Rich Clients" ( though they throw in Macromedia Flash ). Which essentially are ASP.NET driven pages which can be manipulated by back-end assemblies. The example shown at:
http://www-106.ibm.com/developerworks/java/library/j-struts/
( almost half-way down the page ) is a model which can be implemented by server-side ASP and C#/VB components. You'd be using the MTS/MSMQ "parts" of.NET.
What ? And you're the RMI Interface STUD, are you ? It's NO different than coding a COM interface. Or are you that deluded into thinking that running regsvr32 is SO much more difficult than dealing with rmiregistry ?
Oh ? You're using rmic ? Well...I thought you were using nothing more than a text editor to generate your stubs ?
Because too often you have to wonder about what version some server component is under Java RMI ( because the Corba implementation you had to use didn't support it ). And, more importantly, because it's no harder to write IDL than designing Java RMI interface stubs.
When the PLUMBING to YOUR CORBA enterprise application gets plugged.....who're you going to blame, the JVM ?
Both of the previous replies respond to your point as well. But I don't see any language you've got listed up there who doesn't have some adapability to being able to utilize COM objects in one form or another ( When implemented on Windows, of course. ).
I remember when CORBA was really "gathering steam" ( at least from the number of contracting projects out there calling for it ), and remember seeing some of my OOD/OOP bretheren head off to Corba-based projects. I can think of only two of them who ever said that their project achieved their goals. SPECIFICALLY, in one case, because of what one of the other respondents to your post state....SPOTTY implementations.
You want to see.NET Threading...look at Java...similar behavioral patterns...why do you think they put in Delegates ? For the same reason you make use of event listeners in Java.
Not that you'd WANT to do multi-threading in Java ( or.NET for that matter ).
You want pain....try implementing version on a Java RMI-based app.....
As for barely surviving coding in COM...what God-forsaken tools were you relegated to using ? Clay tablets and a stylus ( Maybe you were coding for the Tablet PC, who knows ? )?
regardless of the fact that he used incomplete sentence construction ( Yeah, attack the person's grammar.).....the fact that he is using his experience to say that Solaris ( insert your OS here ) was used everwhere he's worked for over the past 4 years, kind of implies it.
I take back my beratement of you earlier for programming in VB....well said....
And as for Java RMI...puhleeze..easy ? GMAB...I program in both Java and C++ ( and a few other languages )...and Java RMI is not by ANY means a simpler a distributed method invocation invocation interface, than DCOM is...as a matter of fact, from what "Java Examples" from O'Reilly says, that deploying implementation stubs of server interfaces ( and I quote ), can be "burdensome".....they go on to explain how you go about this. I remember when I first read about this about 2 1/2 (!) years ago, and thinking to myself.....$hit, that doesn't sound very much different than, DCOM in the amount of work effort required. Not to mention you have to set up your security manager to have the proper policies set to allow RMI clients to make the necessary network connections to communicate with the server side pieces ( Geez...doesn't sound that much different than dealing with MTS/MSMQ ). So what you're left with is versioning, which JAVA RMI ( from what little information I've ever come across ) doesn't really address at ALL......which now, supposedly ( hey, I have to be objective ).NET will do for you ( versus having to implement our own versioning management system, which we did ).
I'd say that's more a reflection on the programmer's skill and/or knowledge of the programming language than utility provided. Sure VB dumbifies things ( Hell, you can even pseudo-do stored procedures in MS ACCESS, if you implement things in VBA ). C++ Builder also supports creating COM Server components as well....check it out...download a trial version of it....What you'll see is what MS has only gotten around to puttin into Visual Studio until just this year ( and Builder's been around a few years already ).....You want component programming....Builder and Delphi are far and away ahead of the curve. And let's not forget Kylix for our Linux friends...
Just because your shop does, doesn't mean that there aren't shops out there, that have corporate environment applications which deploy with Windows Server ( in one form or another running some sort of another of a database ) on the backend....
It's certainly not the defacto for email servers ( thank &Deity )...
I'm not the first one ( as a/. article earlier today mentioned ) to say this...and probably not the last...but Linux/Unix serves best as the underpinning for backend processes, and Windows running on the client.
While this may be my first post to be classified as "Troll"...here goes...
A) Clearer documentation B) Though built on ( unstable as dung Windows ), it does DO what it purports to do, and without as many poodle loops as you have to jump with Corba and J2EE
Though...just because you can "grasp" DCOM doesn't mean you want to "jerk" around with it....you know...having to deal with that whole "hairy palms" business, and such.
The Alva unit may be nice, but more than likely, it's considerably more expensive than he might be prepared to spend....Though I will wholeheartedly agree with you, that this unit appears to fit the bill ( especially since it's tri-band )..the question is...how much is it ? The website for it makes ZERO mention of how much DINERO ($$$) it costs.
well...there's Symbian, and then there's Series 60. Symbian is the OS, and Series 60 is the UI implemented on top of Symbian ( 6.1 in the case of most Newer Nokia Phones ).
The reason I suggested that rather than Java is more because for things like Accessibility, and "closer to the base UI", designing and implementing his application that way, would best suit the purpose ( at least, as he's laid out his intentions that it should ).
Either way, he's got a fair bit of work ahead. The amount of good documentation for developing Mobile Symbian applications is relatively scarce. Limited to 4 ( still in print ) books, two of which I've read, and one which I posted a review for on Amazon. Since his application isn't necessarily GUI-based, he'll have to learn
both the Symbian OS arch as well as the niceties of Series 60.
It'll most likely would have to have some sort of GUI applet to complement it ( for configuration, etc. ) so that a person can configure it for the phone and the user before they begin to use it.
Yes..but the software they're talking about are running on the 9200 communicators. Mind you, these units
A) Are fast growing out of date with newer systems B) Aren't in implemented in Java, rather their OS is a flavor of the Symbian OS called Series 80.
Personally, I think that a Symbian OS based phone would be the way to go. What you would have to do is record audio bits ( rather compressed I'm sure ), that would correspond to the most commonly used features of the particular phone that you're implementing this on. That way, when the user pressed a particular key, he or she would hear either something spoken to them that says what either the key means ( a number on the keypad ) or what the menu name they've just selected means.
I think some of the newer series 60 phone "MIGHT" be ideal for this based on both feature set and price. A UIQ based phone is still in the $650+ range ( and 9200 communicators are in the $600 range as well ).
Having your application run as a Symbian service would allow it to be "aware" of the state of the UI.
Any way you slice it...it'd be a fair bit of work, and I'm sure that it must've cost Vodafone a pretty penny to get that software implemented even on that limited number of phones.
The evidence is that the ninny who wrote this drivel has this as an email address in his article, on the gartner website ( Just look at the by-line at the top of article ).....
----> javascript:void(null)
Which is about how much of a case SCO truly has on Linux. And how much Mr. Weiss' opinion is really worth.
The link actually pulls up an "autobiography" of the user....I just though that the HREF in the link was rather "fitting" in context of the discussion.
And the fact that he lists himself as the only analytical source, is also amusing. He makes no comment as to whether he's actually signed the NDA and "seen for himself" if in fact SCO "has a leg to stand on". Yup, just the sort of analysis I would trust from a market research firm of the "stature" of the Gartner Group.
EXACTLY !!!! Give the man a cigar ( or a cold one, whatever. ) !
This is exactly what I'm talking about....it'll have to be to each complacent individual to get off their collective couch ( or $1500 ergonomic chair ), and innovate. How ? Maybe a few less brewski for the couch jockeys...and maybe a few less triathlons, eh, lance armstrong wannabes ?
It doesn't mean that you'll stick it out until midnight at your local neighborhood cubicle, but maybe a bit less time developing your Greedo knock-off character in Star Wars Galaxies, or worrying about becoming a platoon leader in Planetside.
Jesus H. ! Why not grab the specs for that new Dragon processor from China ( as lame as you might think it is ), learn the damn thing. Become so proficient in it's architecture that the chinese GOVERNMENT will have to hire you to get the best programmer to write software for THEIR baby. That's innovation. Take it to them, don't let it be taken from you.
I know all about it happening to textile workers, my mother was one for 25 years, and put me through college that way. Yet while, my mom came here to escape communism, and try to build a better life for herself ( as many H1B's do ), SHE was willing to do a job that already american citizens WEREN'T.
Not necessarily, the same case with all IT jobs being "exported".
The situation may not be cyclic, but frankly, if you look at the set of Yourdon's books which came out in the 90's. Sure, some of the concepts were a little A$$-skewed, but frankly, the core IDEA was correct.
A) We,American software engineers became complacement.
B) We bought into the corporate "hype"
C) We let the A$$ clowns running the organization
dictate ridiculous promises of deliverables and insane schedules.
The long and the short of it...if things are to change, the IT community has to turn things around itself. The statement "no programmer is indispensible" may not be overturned, but bitchin' about it, isn't going to change the flow.
Are you nuts ? Have you ever tried using tech support call centers outside the country for anything of useful purpose ? Consider that DELL does this now, and there is nothing but discontent among customers ( and I'm not just talking about US customers, so that dispels the "US consumer as whiner" myths ).
Slashdot Mirror
What the HELL do you mean by "decipher the insane implementation behind the \"smoke and mirrors\" ?
The idea is that you're NOT SUPPOSED to both with it. Interfaces are there to be used, not reverse engineered. If you wanted to know what the F$%#king component was doing, you should've bought the source license.
Visual Studio 6 was absolutely the WRONG IDE to use.
Good....you got your "A" in grammar now.
DUUDE !! You have GOT to switch to DE-CAF....!
I second the last poster's vote...Retard...Fire the guy who put you in charge of handling the build !
There is...in this months ( Sept 2003 ) .Net magazine, there's an article about what they call "Rich Clients" ( though they throw in Macromedia Flash ). Which essentially are ASP.NET driven pages which can be manipulated by back-end assemblies. The example shown at:
http://www-106.ibm.com/developerworks/java/library /j-struts/
( almost half-way down the page ) is a model which can be implemented by server-side ASP and C#/VB components. You'd be using the MTS/MSMQ "parts" of .NET.
What ? And you're the RMI Interface STUD, are you ? It's NO different than coding a COM interface. Or are you that deluded into thinking that running regsvr32 is SO much more difficult than dealing with rmiregistry ?
Oh ? You're using rmic ? Well...I thought you were using nothing more than a text editor to generate your stubs ?
Because too often you have to wonder about what version some server component is under Java RMI ( because the Corba implementation you had to use didn't support it ). And, more importantly, because it's no harder to write IDL than designing Java RMI interface stubs.
When the PLUMBING to YOUR CORBA enterprise application gets plugged.....who're you going to blame, the JVM ?
That's funny....you and I had the same Doctor.
Both of the previous replies respond to your point as well. But I don't see any language you've got listed up there who doesn't have some adapability to being able to utilize COM objects in one form or another ( When implemented on Windows, of course. ).
I remember when CORBA was really "gathering steam" ( at least from the number of contracting projects out there calling for it ), and remember seeing some of my OOD/OOP bretheren head off to Corba-based projects. I can think of only two of them who ever said that their project achieved their goals. SPECIFICALLY, in one case, because of what one of the other respondents to your post state....SPOTTY implementations.
You want to see .NET Threading...look at Java...similar behavioral patterns...why do you think they put in Delegates ? For the same reason you make use of event listeners in Java.
.NET for that matter ).
Not that you'd WANT to do multi-threading in Java ( or
You want pain....try implementing version on a Java RMI-based app.....
As for barely surviving coding in COM...what God-forsaken tools were you relegated to using ? Clay tablets and a stylus ( Maybe you were coding for the Tablet PC, who knows ? )?
regardless of the fact that he used incomplete sentence construction ( Yeah, attack the person's grammar.).....the fact that he is using his experience to say that Solaris ( insert your OS here ) was used everwhere he's worked for over the past 4 years, kind of implies it.
I take back my beratement of you earlier for programming in VB....well said....
.NET will do for you ( versus having to implement our own versioning management system, which we did ).
And as for Java RMI...puhleeze..easy ? GMAB...I program in both Java and C++ ( and a few other languages )...and Java RMI is not by ANY means a simpler a distributed method invocation invocation interface, than DCOM is...as a matter of fact, from what "Java Examples" from O'Reilly says, that deploying implementation stubs of server interfaces ( and I quote ), can be "burdensome".....they go on to explain how you go about this. I remember when I first read about this about 2 1/2 (!) years ago, and thinking to myself.....$hit, that doesn't sound very much different than, DCOM in the amount of work effort required. Not to mention you have to set up your security manager to have the proper policies set to allow RMI clients to make the necessary network connections to communicate with the server side pieces ( Geez...doesn't sound that much different than dealing with MTS/MSMQ ). So what you're left with is versioning, which JAVA RMI ( from what little information I've ever come across ) doesn't really address at ALL......which now, supposedly ( hey, I have to be objective )
I'd say that's more a reflection on the programmer's skill and/or knowledge of the programming language than utility provided. Sure VB dumbifies things ( Hell, you can even pseudo-do stored procedures in MS ACCESS, if you implement things in VBA ). C++ Builder also supports creating COM Server components as well....check it out...download a trial version of it....What you'll see is what MS has only gotten around to puttin into Visual Studio until just this year ( and Builder's been around a few years already ).....You want component programming....Builder and Delphi are far and away ahead of the curve. And let's not forget Kylix for our Linux friends...
Neither is Solaris....I'd be surprised if it's 15%
And here's a little number for you...most small lans ( whethere they're managed by a Domain Controller or not ), run off of Windows.
Get Lawyers to run their networks with Linux servers as the backend...and THEN we're talking market penetration.
Probably because you were using the wrong tools.
C++ Builder is FAR, and AWAY to work with then any of the Visual Studio product ever were.
Hell...I'm using it now...want to use a third party ActiveX control ( even a one written in Stupid VB ), just bring it in.
Just because your shop does, doesn't mean that there aren't shops out there, that have corporate environment applications which deploy with Windows Server ( in one form or another running some sort of another of a database ) on the backend....
/. article earlier today mentioned ) to say this...and probably not the last ...but Linux/Unix serves best as the underpinning for backend processes, and Windows running on the client.
It's certainly not the defacto for email servers ( thank &Deity )...
I'm not the first one ( as a
While this may be my first post to be classified as "Troll"...here goes...
A) Clearer documentation
B) Though built on ( unstable as dung Windows ),
it does DO what it purports to do, and without as many poodle loops as you have to jump with Corba and J2EE
Though...just because you can "grasp" DCOM doesn't mean you want to "jerk" around with it....you know...having to deal with that whole "hairy palms" business, and such.
The Alva unit may be nice, but more than likely, it's considerably more expensive than he might be prepared to spend. ...Though I will wholeheartedly agree with you, that this unit appears to fit the bill ( especially since it's tri-band )..the question is...how much is it ? The website for it makes ZERO mention of how much DINERO ($$$) it costs.
well...there's Symbian, and then there's Series 60. Symbian is the OS, and Series 60 is the UI implemented on top of Symbian ( 6.1 in the case of most Newer Nokia Phones ). The reason I suggested that rather than Java is more because for things like Accessibility, and "closer to the base UI", designing and implementing his application that way, would best suit the purpose ( at least, as he's laid out his intentions that it should ). Either way, he's got a fair bit of work ahead. The amount of good documentation for developing Mobile Symbian applications is relatively scarce. Limited to 4 ( still in print ) books, two of which I've read, and one which I posted a review for on Amazon. Since his application isn't necessarily GUI-based, he'll have to learn both the Symbian OS arch as well as the niceties of Series 60. It'll most likely would have to have some sort of GUI applet to complement it ( for configuration, etc. ) so that a person can configure it for the phone and the user before they begin to use it.
Yes..but the software they're talking about are running on the 9200 communicators. Mind you, these units
A) Are fast growing out of date with newer systems
B) Aren't in implemented in Java, rather their OS is a flavor of the Symbian OS called Series 80.
Personally, I think that a Symbian OS based phone would be the way to go. What you would have to do is record audio bits ( rather compressed I'm sure ), that would correspond to the most commonly used features of the particular phone that you're implementing this on. That way, when the user pressed a particular key, he or she would hear either something spoken to them that says what either the key means ( a number on the keypad ) or what the menu name they've just selected means.
I think some of the newer series 60 phone "MIGHT" be ideal for this based on both feature set and price. A UIQ based phone is still in the $650+ range ( and 9200 communicators are in the $600 range as well ).
Having your application run as a Symbian service would allow it to be "aware" of the state of the UI.
Any way you slice it...it'd be a fair bit of work, and I'm sure that it must've cost Vodafone a pretty penny to get that software implemented even on that limited number of phones.
----> javascript:void(null)
Which is about how much of a case SCO truly has on Linux. And how much Mr. Weiss' opinion is really worth.
The link actually pulls up an "autobiography" of the user....I just though that the HREF in the link was rather "fitting" in context of the discussion.
And the fact that he lists himself as the only analytical source, is also amusing. He makes no comment as to whether he's actually signed the NDA and "seen for himself" if in fact SCO "has a leg to stand on". Yup, just the sort of analysis I would trust from a market research firm of the "stature" of the Gartner Group.
This is exactly what I'm talking about....it'll have to be to each complacent individual to get off their collective couch ( or $1500 ergonomic chair ), and innovate. How ? Maybe a few less brewski for the couch jockeys...and maybe a few less triathlons, eh, lance armstrong wannabes ?
It doesn't mean that you'll stick it out until midnight at your local neighborhood cubicle, but maybe a bit less time developing your Greedo knock-off character in Star Wars Galaxies, or worrying about becoming a platoon leader in Planetside.
Jesus H. ! Why not grab the specs for that new Dragon processor from China ( as lame as you might think it is ), learn the damn thing. Become so proficient in it's architecture that the chinese GOVERNMENT will have to hire you to get the best programmer to write software for THEIR baby. That's innovation. Take it to them, don't let it be taken from you.
Not necessarily, the same case with all IT jobs being "exported".
The situation may not be cyclic, but frankly, if you look at the set of Yourdon's books which came out in the 90's. Sure, some of the concepts were a little A$$-skewed, but frankly, the core IDEA was correct.
A) We,American software engineers became complacement. B) We bought into the corporate "hype" C) We let the A$$ clowns running the organization dictate ridiculous promises of deliverables and insane schedules.
The long and the short of it...if things are to change, the IT community has to turn things around itself. The statement "no programmer is indispensible" may not be overturned, but bitchin' about it, isn't going to change the flow.
And it's not just level 1 support, either.