Sanity check
-
You bring up a lot of great ideas. The problem is, they make too much for sense the hypothetical situation to which I refer. :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleNo the problem was that i was a little drunk and getting a little sober the same time since since my six pack was finsihed while being confronted with a hypothetical situation:)
With friendly greetings,:) Eric Goedhart Interbritt
-
code-frog wrote:
Seriously?
100% serious, my man. As they say, "homey don't play dat."
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleI think that's very cool. You did your employer a favor. You got out of their way so that if they are intent on this they can find the right people and shake it out. You also did them a favor by sending a strong message that maybe they are on the wrong track.:cool:
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
What is Enterprisey[^]? For the win Alex.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
-
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[
Why write *any* of it in C# - write it all in C++ with MFC/WTL/wxWindows (plus generous helpings of Boost (the serialisation library could be handy) - then the interop problems go away (apart from the inconvenient thing that none of you have C++ experience). All uses of XML in that scenario are dumb - the rules engine would be better off using a DSL and custom parser, I suspect. The database schema changing thing doesn't sound too tricky - the queries need to be written to just fetch all columns (the joins would stay invariant, I presume) and obviously you need to query the schema for column details. The biggest issue of the lot is the obvious disconnect between management and the proletarian rabble ;P PS - have you mentioned Mono[^] to the management at all? Cross -platform in .NET...although I don't know what the class library's like.
-
Percival Watson wrote:
Why did mgmt hire developers if they obviously know how to implement it themselves?
Because...umm....well....errr.......XML! That's right, XML! :~
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - AristotleWait until they tell you it has to be SOA. And integrate with the Oracle, BEA an IBM SOA suites. Then the XML will make sense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
Chris Meech wrote:
I've heard that it was snowing recently in Bullhead Arizona,
Conclusively proving that, contrary to some rumors, Bullhead is not Hell.
Hell wishes it was Bullhead.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
Wait until they tell you it has to be SOA. And integrate with the Oracle, BEA an IBM SOA suites. Then the XML will make sense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . not.
regards, Percival Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
What is Enterprisey[^]? For the win Alex.
Using the GridView is like trying to explain to someone else how to move a third person's hands in order to tie your shoelaces for you. -Chris Maunder
Andy Brummer wrote:
What is Enterprisey[^]? For the win Alex.
Man, you hit the nail on head. Good one! :)
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Why write *any* of it in C# - write it all in C++ with MFC/WTL/wxWindows (plus generous helpings of Boost (the serialisation library could be handy) - then the interop problems go away (apart from the inconvenient thing that none of you have C++ experience). All uses of XML in that scenario are dumb - the rules engine would be better off using a DSL and custom parser, I suspect. The database schema changing thing doesn't sound too tricky - the queries need to be written to just fetch all columns (the joins would stay invariant, I presume) and obviously you need to query the schema for column details. The biggest issue of the lot is the obvious disconnect between management and the proletarian rabble ;P PS - have you mentioned Mono[^] to the management at all? Cross -platform in .NET...although I don't know what the class library's like.
Stuart Dootson wrote:
The database schema changing thing doesn't sound too tricky - the queries need to be written to just fetch all columns (the joins would stay invariant, I presume) and obviously you need to query the schema for column details.
Ah, keep in mind that all communication with the data access layer must be done via XML because it is written in C++. So, directly querying the schema is out. One option is embedding schema info in the XML resultset like <foo id="0" id_type="int" />. Another is to include the XML resultset schema in the resultset itself, but both of these options are completely absurd, IMO. Also, providing a generic means of specifying how to validate some new column in a grid is involved. When a new field is included in a query result, that new field must show up in a grid and be validated before saving it. It's possible to do, but "sometime in March" is not. Mono was mentioned earlier in this thread. No way, Jose.
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
I think that's very cool. You did your employer a favor. You got out of their way so that if they are intent on this they can find the right people and shake it out. You also did them a favor by sending a strong message that maybe they are on the wrong track.:cool:
code-frog wrote:
You did your employer a favor.
Trust me, I did them no favor. In this hypothetical scenario, I am pretty much the only dev working on the C# client app. The rest of the team is working on the C++ libraries. No, I did them no favor at all. I simply pressed the big red EJECT button when I saw that the plane was flying straight toward the ground at maximum velocity.
:josh: My WPF Blog[^]
We are what we repeatedly do. Excellence then, is not an act, but a habit. - Aristotle -
Please review this completely hypothetical (:rolleyes:) scenario and let me know if you think it's totally nuts: A relatively simple application needs to be created. It could all be implemented in C# as a fat client app, but mgmt decides that some day part of the app might need to run on a server. The server might be Windows, or it might be Linux. So, all "business functionality" and the data access layer must be written in unmanaged C++, even though it's entirely possible that the "business functionality" will never make it to a server. Of course, this introduces a slew of the wonderful mananged-unmanaged interop issues. Naturally, nobody on the team really has any expertise in C++. BTW - can't use Java, even though it satisfies the cross-platform requirements. Nope, it has to be C++ because mgmt says so. Honest. Mgmt decides that the C#-to-C++ interop must only communicate via XML. No particular reason why, but it must be XML. This means taking .NET business objects, manually serializing them to XML (can't use SoapFormatter), then (in the same Windows process) deserializing the XML into C++ business objects, manipulating them, serializing the modified C++ objects back to XML, and finally deserializing them back into .NET objects again. There's more. Part of the app needs to process some business rules and validate input data. Since that falls under the category of "business functionality" an entire rules engine must be written from scratch in C++. And, naturally, it must use XML to define the business rules. Why XML? Because mgmt says so. I'm not even done yet... The "C# client app" (I use that term extremely loosely since the whole app runs in one process) must be written in such a way that the database schema can change at any time. They should be able to add in new columns to any table and the app must "just work." If one of the users asks for a new column or two in some table and then they go ahead create the columns, the client app should just show those new fields and allow the user to update and save them. Redeploying the app can take two weeks, and the users don't want to wait that long for their whims to be satisfied. The deadline is "sometime in March." Am I going crazy, or is this hypothetical situation completely ridiculous?
:josh: My WPF Blog[