If an american brings his family to Canada, his family can work in Canada. If a Canadian works on a TN his family is allowed to join him, but they all have to sit at home all day and if they want to work, too bad.
It isn't a preferable situation if you have a wife and kids.
What do they do?
USA residents can have their wives and children work on NAFTA visas in Canada - the USA was supposed to do the same. That would cut down on a bunch of very unnecessary Green Card applications!
Expect to be REALLY exploited. Canada has no law saying foreigners MUST be paid equivalent to citizen wages, which explains the body shops.
The social programs and health care is a total fraud to justify higher taxes, they don't fund it, if you've a booboo on your finger they'll patch it, need heart surgery, the waiting list is years.
And 60% of your income will go in taxes, and you'll be paid in a worthless currency.
I support Canadians like myself being able to move to the USA. The Prime Minister himself told us if we didn't like Canada we were welcome to f off. Consider me f'd off.
Less'n of course part of the deal is that Corel decides, for "strategic" reasons, to stop selling the "poorly performing" Linux and go with.NET instead.
Thanks for the kudos on the C API bit. I find GNOME code ugly to look at.
GNOME code would be much cleaner in C++ because of the way it merges nicely with a "respond to event" environment like GNOME, or any other GUI for that matter.
I think I remember reading the reason why they balked at using C++ is that they were concerned about making it portable even to environments that didn't support C++.
Inti looks like an interesting framework, will let you guys know what I think when I've had a chance to play with it.
Well, you realise that you're just about developing for Windows ONLY with that kind of approach.
ATL is nice inasmuch as you're not carting around the enormous baggage of MFC and all it entails with you (big DLL) esp when having to move instances of interfaces between machines.
Just remember when dealing with ActiveX you're dealing with an interface and not an actual object, and you'll be OK.
Oh yeah, keep in mind that BSTR and OLECHAR* are not the same thing, even though the compiler won't be able to tell the difference, and one's typedef'd as the other, and it works in a lot of cases.
I agree with the reply that says that this isn't OO, but let me mention that Redmond has found that its macro messaging architecture is faster than using virtual functions, hence the design.
As for there being no main function, you're dead wrong. WinMain is a part of the class library.
RE: "I mean... how hard can it be to read the clear MSDN explanation of an MFC method..."
Unless of course, you're dealing with the various gotchas you have to find out about yourself, such as the fact that CMap leaks memory - certain GDI functions don't work the same between Win9x and WinNT, mapping modes between CScrollView and items you're trying to draw within CScrollView are different, don't forget to map the points back and forward...
MFC generates Message Maps and macros rather than using virtual functions in its frameworks. The official Redmond Party Line on this is that speed is enhanced by using such an unholy mess. And speaking of unholy mess, sure it works, but you try dealing with scrolling views and having to convert back and forth between mapping modes and you're just about ready to scream "WHY DIDN'T YOU STANDARDISE THIS, CRETIN" at the nearest NT apologist.
GTK isn't OO either - it's a C API.
MFC's strengths don't lie in its technical implementation, but the fact that there is a half-decent application generator that spits out this code. If you want an application with a window, view, document, serialisation support etc etc etc all you have to do is fire up VC++ and run AppWizard.
What Linux development sorely needs is some kind of framework (Inti's a nice start) plus a half decent open source appbuilder that wraps around gcc and gdb. Would you like a default MDI application in KDE? BAM there you go, and INSERT CODE HERE. Ditto GNOME.
Freeing up the developer from pointless busywork is the key. Right click on the class, type in the function signature, BAM, there's your code.
I can here the vi guys choking right now, and some EMACS type is going to chime up that you can actually do that with some custom LISP script, but if we're going to try to leverage MFC leveraging what it does well is important.
If #3 happens, then all the hackers slackers and pistol packers should forcibly grab a handgun each and then take over some unused mass of land, cashing in their stock options and building a new country in the middle of nowhere and setting up the coolest infrastructure in no time flat.
Then they could run TCPIP all they want, run Open Source, and make corporations illegal within the country limits.
What's wrong with that common and garden standby, the TEXT FILE?
You can print it, import it to the editor of your choice, quote from it, view it in a Web browser, grep it, search it with the tool of your choice, and for all intents and purposes it's virtually universally readable.
Why wrap it in some weird technology?
Well, I'm sure I am. I'm not ashamed of it, either. When I put a disk in the drive, I want to have some idea of what I'm doing, and not have to wonder if I should buy some sixty dollar book just to figure out the quirks and quarks of an install.
I never noticed anything about an apt in the install. All I saw was a list of things, when I pushed enter it went to another screen and I couldn't get back to the original. Not very intuitive.
Start out, definitely, by offering certain pre-packaged "sets" of install classes: minimal, X station, GNOME station, KDE station.
There should also be a "Wizard" like Q and A session which asks the user salient questions about the install: like,
a) what kernel would you want to use?
b) do you want to network?
c) do you wish to use X?
d) what windowmanager(s) do you wish to use?
e) etc.
to "layer" certain classes of install on top of each other.
Any selection of a package should select all dependencies.
I should be able to tell when I've selected a package or not. VERY LITTLE window thrashing should be required. I tried Debian's install and it drove me crazy, I was in an infinite loop of window thrashes.
1) Getting credit (but you don't live here.)
2) Family? (Hey, dear, sorry your life is on hold four years and counting...)
If they only let spouses and children of TNs work like they said they would, and like Canada has done (you go to Canada on a US equiv of a TN-1 and the wife and kids can work!) you'd have less people applying for Green cards.
Wrong. First of all, A TN is only available for a period of less than one year.
You can only work as a "Computer Systems Analyst" - not a programmer.
And since there's no track to a Green Card, if you have a family, what do you do? Tell them they can never work, ever?
Re:Given how cheap DVD drives are, does this matte
on
Copying A DVD To A CD?
·
· Score: 1
Back in 1996, I was asked at work by a co-worker if I knew of a way to copy DVDs "for cheap", unquote.
The gentleman in question came from a country in which copyright is an amusing idea, why you buy something if you get it for free?
I don't think he was intending on backing up his pristine copies of the Matrix, I do know he was offering me money to figure out how to do this. Apparently he was tasked by "friends" to ask around tech people because his "friends" were interested in this idea.
I think he did want to make quite a few copies of DVDs... couldn't for the life of me figure out why...
RE: Hmm. Not sure about this. Management is a priori "heirarchically superior" because the management commands the developers.
Well, I'm arguing that its proper function is horizontal co-ordination, not a Mosaic "message from above".
RE: I also feel you're giving too much power to marketing.
Depends on the organisation. Many are marketing driven. They'll slash tomorrow's throat to sell 20 units this month.
RE: Marketing is not "on the same level" as development, it exists in a totally different dimension, and should be viewed as a necessary thing given that we're developers, not as an end in itself.
I'm saying that if marketing, sales, development, etc. are properly to be viewed as teams, then we can only succeed by having them all on the same level.
RE: I might be misunderstanding you, though, because in the Open Source case you seem to consider marketing as "what the user community wants"
As DISCOVERING the user need and keeping on at it, yes.
Management used to be relatively simple. You had some guy spinning a wrench on an assembly line, and you had some guy in a walrus moustache and a suit fuming and humming and making sure the work got done.
With software projects, management really should be seen as a separate enterprise, not a hierarchically superior one, to development, marketing, etc. You have two basically competing units - marketing (or in the sense of open source, what the user community is looking for) which expects everything under the sun, sure it's possible!, and development, which is asking for time and energy to create a good product to static project requirements.
In a commercial enterprise, management should be about insulating both marketing and development from each other, and making sure that both is on the same phase. Marketing should figure out what the customer really wants, and the development people should put it out on time and bug free. Management should make sure that marketing doesn't decide to abrogate its responsibilities and just nod to every moronic request any customer makes, that development has enough computers, manpower and software to do the job, and completes it to spec, etc.
Now, in terms of open source, the "there is no management" could come from the fact that there's no hierarchy, but the idea of managing a project is no less important. Management in this instance should come from the user base - instead of just creating, say, yet another dock applet mixer, the development team with the idea of doing XYZ should go out and say "do we need X and if so what do we need XYZ to do?" That way, when the English people say they need the steering wheel on the right hand side, and the Americans on the left, we don't build a car with two steering wheels, but one with a wheel that can be put on either side of the car as needed.
The biggest challenge is getting people to stay on track. In a corporate environment, if you don't agree with the spec, do it or quit. In Open Source, if you don't agree with the spec, split the development effort by fracturing the team, or whine.
Slashdot Mirror
CAN THEY WORK?
Case closed.
If an american brings his family to Canada, his family can work in Canada. If a Canadian works on a TN his family is allowed to join him, but they all have to sit at home all day and if they want to work, too bad.
Read ALL the words. Even the big ones.
It isn't a preferable situation if you have a wife and kids.
What do they do?
USA residents can have their wives and children work on NAFTA visas in Canada - the USA was supposed to do the same. That would cut down on a bunch of very unnecessary Green Card applications!
Expect to be REALLY exploited. Canada has no law saying foreigners MUST be paid equivalent to citizen wages, which explains the body shops.
The social programs and health care is a total fraud to justify higher taxes, they don't fund it, if you've a booboo on your finger they'll patch it, need heart surgery, the waiting list is years.
And 60% of your income will go in taxes, and you'll be paid in a worthless currency.
I support Canadians like myself being able to move to the USA. The Prime Minister himself told us if we didn't like Canada we were welcome to f off. Consider me f'd off.
Nope. Beyond that. As in a big-ass page with huge RED LETTERS saying "Here's the fifty million things you need to do to fix this thing."
I tried building something with INTI in it - and the whole include tree is scuppered.
ODBC driver doesn't appear to work...
I KNEW gcc was going to be a problem, but did it anyway.
There NEEDS to be some kind of damage control saying "If you're using 7.0 do X,Y,Z"
Less'n of course part of the deal is that Corel decides, for "strategic" reasons, to stop selling the "poorly performing" Linux and go with .NET instead.
Thanks for the kudos on the C API bit. I find GNOME code ugly to look at.
GNOME code would be much cleaner in C++ because of the way it merges nicely with a "respond to event" environment like GNOME, or any other GUI for that matter.
I think I remember reading the reason why they balked at using C++ is that they were concerned about making it portable even to environments that didn't support C++.
Inti looks like an interesting framework, will let you guys know what I think when I've had a chance to play with it.
Actually, I didn't. Thanks for the info. Where do I find a tutorial on coding new templates?
Thanks for responding. I'll look at KDevelop again.
Not really - I'm not into TrollTech's "now it's GPL now it isn't" licensing scheme, nor KDE developers' insulting attitude to GNOME programmers.
I'm referring to a KDevelop kind of thing for ALL Linux platforms, including XFCE, GNOME and KDE.
Well, you realise that you're just about developing for Windows ONLY with that kind of approach.
ATL is nice inasmuch as you're not carting around the enormous baggage of MFC and all it entails with you (big DLL) esp when having to move instances of interfaces between machines.
Just remember when dealing with ActiveX you're dealing with an interface and not an actual object, and you'll be OK.
Oh yeah, keep in mind that BSTR and OLECHAR* are not the same thing, even though the compiler won't be able to tell the difference, and one's typedef'd as the other, and it works in a lot of cases.
I agree with the reply that says that this isn't OO, but let me mention that Redmond has found that its macro messaging architecture is faster than using virtual functions, hence the design.
As for there being no main function, you're dead wrong. WinMain is a part of the class library.
RE: "I mean... how hard can it be to read the clear MSDN explanation of an MFC method..."
Unless of course, you're dealing with the various gotchas you have to find out about yourself, such as the fact that CMap leaks memory - certain GDI functions don't work the same between Win9x and WinNT, mapping modes between CScrollView and items you're trying to draw within CScrollView are different, don't forget to map the points back and forward...
MFC generates Message Maps and macros rather than using virtual functions in its frameworks. The official Redmond Party Line on this is that speed is enhanced by using such an unholy mess. And speaking of unholy mess, sure it works, but you try dealing with scrolling views and having to convert back and forth between mapping modes and you're just about ready to scream "WHY DIDN'T YOU STANDARDISE THIS, CRETIN" at the nearest NT apologist.
GTK isn't OO either - it's a C API.
MFC's strengths don't lie in its technical implementation, but the fact that there is a half-decent application generator that spits out this code. If you want an application with a window, view, document, serialisation support etc etc etc all you have to do is fire up VC++ and run AppWizard.
What Linux development sorely needs is some kind of framework (Inti's a nice start) plus a half decent open source appbuilder that wraps around gcc and gdb. Would you like a default MDI application in KDE? BAM there you go, and INSERT CODE HERE. Ditto GNOME.
Freeing up the developer from pointless busywork is the key. Right click on the class, type in the function signature, BAM, there's your code.
I can here the vi guys choking right now, and some EMACS type is going to chime up that you can actually do that with some custom LISP script, but if we're going to try to leverage MFC leveraging what it does well is important.
ASCII works fine for diagrams. When it comes to image formats, that's another discussion in itself.
If you truly NEED such formatting, why not HTML?
If #3 happens, then all the hackers slackers and pistol packers should forcibly grab a handgun each and then take over some unused mass of land, cashing in their stock options and building a new country in the middle of nowhere and setting up the coolest infrastructure in no time flat.
Then they could run TCPIP all they want, run Open Source, and make corporations illegal within the country limits.
What's wrong with that common and garden standby, the TEXT FILE? You can print it, import it to the editor of your choice, quote from it, view it in a Web browser, grep it, search it with the tool of your choice, and for all intents and purposes it's virtually universally readable. Why wrap it in some weird technology?
Well, I'm sure I am. I'm not ashamed of it, either. When I put a disk in the drive, I want to have some idea of what I'm doing, and not have to wonder if I should buy some sixty dollar book just to figure out the quirks and quarks of an install.
I never noticed anything about an apt in the install. All I saw was a list of things, when I pushed enter it went to another screen and I couldn't get back to the original. Not very intuitive.
Start out, definitely, by offering certain pre-packaged "sets" of install classes: minimal, X station, GNOME station, KDE station.
There should also be a "Wizard" like Q and A session which asks the user salient questions about the install: like,
a) what kernel would you want to use?
b) do you want to network?
c) do you wish to use X?
d) what windowmanager(s) do you wish to use?
e) etc.
to "layer" certain classes of install on top of each other.
Any selection of a package should select all dependencies.
I should be able to tell when I've selected a package or not. VERY LITTLE window thrashing should be required. I tried Debian's install and it drove me crazy, I was in an infinite loop of window thrashes.
More like
FREE* pOffer;
GOTCHA* pYerScrewed = reinterpret_cast (pOffer);
A pointer to FREE can always be NULL...
It's out already. It's called KDE.
I'm switching to Snickers from now on.
I'm at around that too. What sucks is:
1) Getting credit (but you don't live here.)
2) Family? (Hey, dear, sorry your life is on hold four years and counting...)
If they only let spouses and children of TNs work like they said they would, and like Canada has done (you go to Canada on a US equiv of a TN-1 and the wife and kids can work!) you'd have less people applying for Green cards.
Wrong. First of all, A TN is only available for a period of less than one year.
You can only work as a "Computer Systems Analyst" - not a programmer.
And since there's no track to a Green Card, if you have a family, what do you do? Tell them they can never work, ever?
Back in 1996, I was asked at work by a co-worker if I knew of a way to copy DVDs "for cheap", unquote.
The gentleman in question came from a country in which copyright is an amusing idea, why you buy something if you get it for free?
I don't think he was intending on backing up his pristine copies of the Matrix, I do know he was offering me money to figure out how to do this. Apparently he was tasked by "friends" to ask around tech people because his "friends" were interested in this idea.
I think he did want to make quite a few copies of DVDs... couldn't for the life of me figure out why...
RE: Hmm. Not sure about this. Management is a priori "heirarchically superior" because the management commands the developers.
Well, I'm arguing that its proper function is horizontal co-ordination, not a Mosaic "message from above".
RE: I also feel you're giving too much power to marketing.
Depends on the organisation. Many are marketing driven. They'll slash tomorrow's throat to sell 20 units this month.
RE: Marketing is not "on the same level" as development, it exists in a totally different dimension, and should be viewed as a necessary thing given that we're developers, not as an end in itself.
I'm saying that if marketing, sales, development, etc. are properly to be viewed as teams, then we can only succeed by having them all on the same level.
RE: I might be misunderstanding you, though, because in the Open Source case you seem to consider marketing as "what the user community wants"
As DISCOVERING the user need and keeping on at it, yes.
Management used to be relatively simple. You had some guy spinning a wrench on an assembly line, and you had some guy in a walrus moustache and a suit fuming and humming and making sure the work got done.
With software projects, management really should be seen as a separate enterprise, not a hierarchically superior one, to development, marketing, etc. You have two basically competing units - marketing (or in the sense of open source, what the user community is looking for) which expects everything under the sun, sure it's possible!, and development, which is asking for time and energy to create a good product to static project requirements.
In a commercial enterprise, management should be about insulating both marketing and development from each other, and making sure that both is on the same phase. Marketing should figure out what the customer really wants, and the development people should put it out on time and bug free. Management should make sure that marketing doesn't decide to abrogate its responsibilities and just nod to every moronic request any customer makes, that development has enough computers, manpower and software to do the job, and completes it to spec, etc.
Now, in terms of open source, the "there is no management" could come from the fact that there's no hierarchy, but the idea of managing a project is no less important. Management in this instance should come from the user base - instead of just creating, say, yet another dock applet mixer, the development team with the idea of doing XYZ should go out and say "do we need X and if so what do we need XYZ to do?" That way, when the English people say they need the steering wheel on the right hand side, and the Americans on the left, we don't build a car with two steering wheels, but one with a wheel that can be put on either side of the car as needed.
The biggest challenge is getting people to stay on track. In a corporate environment, if you don't agree with the spec, do it or quit. In Open Source, if you don't agree with the spec, split the development effort by fracturing the team, or whine.